Written by

Sr Application Development Analyst at The Ohio State University Wexner Medical Center
Question Scott Roth · Mar 8, 2023

Suspension of Messages during Shutdown

We have messages that are in a queued state for various reasons and when we do a manual shutdown of the instance, they are moved to a Suspended state. I thought I saw in the documentation somewhere a setting to make sure these messages stay in a queued state and not suspend them. Can someone confirm and point me in the correct location for that documentation, as I am trying to ensure that if we do have to manually shutdown a instance, someone doesn't have to remember to go back in and check for suspended messages and resubmit them?

Thanks

Product version: IRIS 2022.1

Comments

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

0
Nicholai Mitchko  Mar 8, 2023 to Vic Sun
set^Ens.Configuration("Queues","KeepInQueues")=1
0
Scott Roth  Feb 16, 2024 to Vic Sun

I just ran through several scenarios of testing the change to Ens.Configuration("Queues","KeepInQueues")=1, but when IRIS was restarted the messages were placed back in the Ens.Suspended queue.

0
Vic Sun  Feb 16, 2024 to Scott Roth

Hi Scott, just to double check that this setting is per namespace. If that isn't working, I'd suggest opening a WRC case.

0
Scott Roth  Jul 24 to Marcel den Ouden

I was never able to get this figured out. It happens because our Business Process sends to a Business Rule that is disabled and started from our cron. 

We just make sure to go check for suspended messages after a fail-over.

0
Marcel den Ouden  Jul 24 to Scott Roth

There is a difference in behaviour for async vs sync messages if I read the documentation. In my case the messages are synchronous, so this should not apply. 

0