AllAccepted answers
Vic Sun · Mar 8, 2023

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."

Vic Sun · Mar 7, 2023

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.

Vic Sun · Mar 2, 2023

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.

Accessing the HTTP Response

set request=##class(%Net.HttpRequest).%New()
 set request.Server="tools.ietf.org"
 set request.Https=1
 set 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()
Vic Sun · Mar 1, 2023

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.

Vic Sun · Feb 22, 2023

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.