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.
Locksiz is only allocated as needed from gmheap, so if gmheap is used up you could be unable to take out further 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.
Reach out to the WRC for this, they can help you reset the global that defines the search criteria.
Yes, assuming the index exists it will be updated as the data changes.
Correct, you can't restore a Cache backup to IRIS. The database files themselves are compatible, but not the backups. You'll need to restore to an instance of Cache.
Hi William,
You found the right part of the documentation. Restoring a cbk file is what is referred to as online backup, so this particular segment would be the step-by-step you need.
Can you identify which components are taking a long time to stop? Often stopping a component being slow is the result of waiting for a synchronous call, for example.
You could use %Dictionary.ClassDefinition to open the class definitions, use %ConstructClone and then save to another namespace.
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?
In that case, I'd recommend reviewing the service user documentation I linked above. If you prefer to not set the service user for whatever reason, then using an admin command prompt would be a perfectly acceptable short term alternative.
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?
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:
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."
Hi Elmahdi,
I saw you commented on another post where I (like Anastasia) pointed to WRC distributions. You are looking for Cache 2017.2.2 which actually is not currently available - that's because InterSystems only freely makes available versions of our software with the latest security improvements. If you need an older kit that isn't currently available on the WRC page, you'll need to either find a copy your organization has on file somewhere, or you can make a special request through InterSystems support.
Back of the napkin here, but I'm guessing that Eduard's dynamic object implementation wasn't available in 2014. 3.5mb seems suspicious as a string size limit so I would suggest trying to read the data into a stream explicitly. ex. from the latest IRIS documentation which I believe may still be pertinent to your use case.
set request=##class(%Net.HttpRequest).%New()
set request.Server="tools.ietf.org"set request.Https=1set request.SSLConfiguration="TEST"set status=request.Get("/html/rfc7158")
if$$$ISERR(status) {
do$system.OBJ.DisplayError()
} else {
set response=request.HttpResponse
}
Set file=##class(%FileCharacterStream).%New()
set file.Filename="c:/temp/rfc7158.html"set status=file.CopyFrom(response.Data)
if$$$ISERR(status) {
do$system.OBJ.DisplayError()
}
do file.%Close()I'm not aware of a sample in our modern documentation but I've put in a request for that. Since pretty much any arbitrary code can be run in ZMIRROR, I don't think there's much guideline for coding ZMIRROR besides the documented tags.
I do think that something like the stubs we document for ZSTART/ZSTOP might be helpful, if that's what you had in mind.
I'm not sure I totally follow your architecture and why looking at the arbiter vs a failover member would be better. It would probably be good to discuss the details with your sales engineer (I'm guessing you're already speaking to them about this). Is the VIP not being handled automatically by the mirror? I saw you commented on some ZMIRROR related posts; I think that would be a good way for your mirror to kick off those non-IRIS failover items automatically on failover, rather than needing to poll.
I would encourage you to review the loss of connectivity scenarios covered in our documentation. The arbiter disconnecting from both sides is not enough to trigger a hang.
https://docs.intersystems.com/irisforhealth20223/csp/docbook/Doc.View.cls?KEY=GHA_mirror_set
A hang suggests a total loss of network connection between failover members and the arbiter simultaneously. In general, the arbiter is a supplement to the communication between the two failover members, and not necessarily the first place to look for an issue.
ex. If the arbiter connections to the failover members were first lost, the primary and failover member would remain in contact via their own ISCAgents. Then, if the two members lost contact with each other, the primary would have continued to operate.
What would be the benefit of querying the arbiter (I'm not sure this is possible) for mirror status vs querying one of the failover members? I also wasn't sure what you meant by non IRIS related.
If you're an existing customer, you can access the distributions through the WRC application. Otherwise Michael's link will let you get a preview copy to test with and review.
I would check the audit log and review the login failures. Access denied is a generic error, the audit log knows more.
Would it be possible to shrink your transaction? I think that would be preferable. If you aren't concerned about data consistency then what is the role of the transaction?
Hi Norman,
I'm not sure I follow exactly what you are trying to do but I think the object concurrency options can provide what you are looking for. Yes - you can avoid locks even when using objects.
I didn't find an option for this but the release note says that as of 2019.3 IRIS queries run in the background.
Definitely reach out to the WRC - another "educated" guess from me on potential causes would be filesystem fragmentation. I've seen that cause databases to fail to expand in the past.
Hi David,
%Operator / the %Admin_Operate resource only give access to the system operation pages so that might be what you want to start with. From there, you can use custom resources to restrict individual pages.
No idea about custom menus!
Can Nessus tell you what in particular is allowing the use of those ssl ciphers? Are you sure it's HealthShare that's causing the issue? Where in HealthShare did you disable the lower TLS version?
It's already been reported, I meant! Rest assured.