To piggyback off this, the initial way to run IRIS under a certain user is to use setserviceusername:

https://docs.intersystems.com/iris20232/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_using_windows#GSA_using_windows_nonadminperm_change

As far as I know you can then update the credentials from services as suggested above, but you may want to keep in mind using setserviceusername if you run into other credentials / Windows permission style issues.

Documentation shows that Java 8 and 11 are supported.

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ISP_technologies#ISP_ejb

11 support was added briefly before Java 17 LTS was released (early 2021 I believe), but it seems InterSystems' Java support has not been updated in the past 2 years. This is something we are working on, however I don't know when that change might be released.

The garbage collector is somewhat an internal process which is why I believe it is sparsely documented. I'd echo Dmitry that understanding your concern would help.

I think what is documented generally covers a high level understanding - that being that there is a GARCOL process. And that blocks are marked freed after a large kill by this process, to be freed in the background.

https://docs.intersystems.com/iris20231/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Config.config#locksiz

If you look at the locksiz class reference, it is described as "An upper bound on the amount of shared memory heap (see gmheap) that is allowed to be consumed by the lock table as a result of application-level locks."

"Deadlock" is too broad to describe any possibility that could cause the instance to hang. I would recommend reaching out to the WRC/support when that occurs so they can analyze the system with you.

FWIW the first place I would look would be the messages.log which would point to next investigative steps. Alexander's IRIShung suggestion is also a good one.

I agree with Lorenzo and Pietro as well! Since I believe you're looking to run tasks/code that has to do with your mirror failing over, I suppose it might be worth taking a higher level look at the scenarios you are hoping to address. Probably most of the things you want to do can be put in your ZMIRROR so that when your new primary takes over it can do whatever miscellaneous non-IRIS failover tasks you want.

What procedures do you need to be concerned about in a clean failover via shutting down the instance (triggering ZSTOP) vs in an unclean failover for whatever reason, in which case you would only expect your ZMIRROR to run?

Hi Mohammed,

This is a fairly common issue with Windows permissions. How are you opening terminal? Are you opening a Windows admin command prompt before entering the IRIS shell? Have you set a service user with the appropriate permissions to run Perfmon, if you are launching terminal from the cube?

https://docs.intersystems.com/iris20223/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_using_windows#GSA_using_windows_nonadminperm_change

Basically, this message is informing you that the user running the terminal (and trying to run SystemPerformance) is trying to open Perfmon and can't. The above are a few things to check.

I would investigate the certs and keys and make sure they are valid for connecting to your end point. You could check things like making sure you have the full certificate chain. I'm afraid IRIS can't really tell you more about why the certificate is being rejected, this is a TLS problem.

My other note would be that TLS 1.1 is deprecated as of 2021 so I would avoid it, and SSL v3 is extremely deprecated so I would avoid it even more strongly.

Hi Scott, that doc is here:

Improving Restarts for Productions with Large Queues

That being said - I thought the move from suspended back to the queue was automatic generally, and wouldn't require a manual resubmit?

"By default, when a production is stopped, any asynchronous messages on the ^Ens.Queue global queue are moved to the ^Ens.Suspended queue. When the production is restarted, they are moved back."