Agreed contact WRC on this and get your messages log from Primary and backup (from during the outage) reviewed. This sounds like a full loss of connectivity or just a hunch are both mirror members backed up at the same time and does this coincide with the outage?

just asking is there a loadbalancer involved when you connect to your application? if so enable stickysession on it so it always reconnects via the same web server as a different webserver means a new session when connecting to iris/cache

Hi Philip,

User and password management in TrakCare is difficult task via SQL and i would not suggest doing it that way.

In newer versions of TrakCare the CodeTable upload manager can be used to batch upload user accounts.

I would suggest you create an iService ticket for TrakCare support to help you with the best option here.

You can always request support to contact me if they need more information on this.

Hi Kari,

this really depends on the authentication options of the 3rd party api.

If the 3rd party api only accept e.g. username/paswords then it will never be more secure even if you use a password vault, as the password needs to be cleartext to be provided to the 3rd party. 

Different story if the api accepts  e.g OAUTH based keys/hashes.
refer to : OAuth 2.0 Client | InterSystems IRIS Data Platform 2022.3

Best Regards

Timo
 

Hi Mark,

there is no issue doing this on a Primary mirror. I have done this multiple times for customers. The system impact with IRIS is negligible. Just remember to do this on all mirror members as DB activities are not replicated only data is.

Just to be on the save side though always check a valid backup is available before you start.

Hi Jonathan,

best way forward is for you to contact WRC, they can help you with the install files and also if needed with a temp license.

just email support@intersystems.com

Depending on the OS you are running you can have firewall rules that redirect the incoming port 80 to another port but its easier to setup a full webserver that publishes your application on port 80/443.

If you don't want to publishg using a full webserver but have it already running you can add rules to it that will redirect request for that webapp to the buildin webserver.

Also need to be aware that the build-in webserver will no longer be included starting from a future version of IRIS, with the exception of community docker image.

Usually the biggest culprit is IRISTemp database. This data base is essentially used for temporary storage of data during the live of a process and can grow quite big if a process misbehaves. The space can usually be reclaimed by setting configuration parameter and restarting IRIS.

The explanation here is the table lock threshold. If a process modifies a certain number of entries within one table without committing it will trigger an escalation from atomic locks per record to a full table lock.

This is configurable but i am not sure about the default value but i think its between 1000 and 10000.

If the lock is triggered essentially all other processes which want to write have to wait until the process has committed its changes which will release the lock.

Solution is to use %NOLOCK if you are sure you will not hit the same record with multiple processes.

Hi,

i am not quite sure why you got BasicAuth enabled on Apache for requests to webservices hosted on IRIS.

I would disable basic auth and use IRIS to authenticate the request, also from a security perspective if the request originates not from localhost i would move to using https.

Main issue with cors is, if the request originates not from the same domain as the target server is in, e.g. server is configured to be at server.sample.loc, that any request not coming from same domain would trigger a cors deny e.g. ip address only.

As cors is only enforced in the browser not the server the question also is how do you call the webservice? From another production? If so, don't care about cors its than only an issue when testing via your browser.

Best Regards

Timo