2

I'm writing an IIB flow that amongst other things generates Event messages (Monitoring functionality). In order to be able to handle all of these events, I need to do a durable subscription. But if I do that, and if the consuming application doesn't come back online for some reason, the QM may fill up and eventually stop. Is there any way to avoid that? Any way to create a managed durable subscription with "forced message expiration"?

spakendralo man
  • 635
  • 2
  • 8
  • 21
  • What do you mean by forced expiration? MQ always forces expiration if set on a message, only the removal of the message is "delayed" until a get reads the message. So if you set the expiry on your event messages, and ensure that an application browses the target queue with appropriate frequency, then the queue won't get full. – Attila Repasi Nov 02 '15 at 21:17

2 Answers2

2

This turns out to be a fairly common use case but one that can be challenging. Of the many approaches possible, here are a few common ones:

Use a circular queue
"Circular queue" is not an official IBM term but something I coined in my article Mission:Messaging: Easing administration and debugging with circular queues. Circular queues are implemented using the Q program from SupportPac MA01 (now on GitHub!) and MQ's native instrumentation to keep the queue trimmed to 80% of MAXDEPTH. This was published in 2011 and based on feedback I've received, I'd guess at least 100 shops are using this automation successfully.

Use MQ v8.0.0.4
As of MQ v8.0 Fix Pack 4, IBM has introduced the CAPEXPIRY attribute on queues and topics. (See: Enforcing lower expiration times) Just set it and forget it.

Automate queue cleanup
Use the Q or QLoad programs to search for messages older than a specified time and remove them. Schedule this using your favorite job scheduler or use MQ instrumentation to look for things like the queue filling up or really long queue service intervals

Don't do this
Durable subscriptions are for things that are supposed to always be present or at least reliably come back. In those cases provision the subscription on deployment and make deletion of the queue part of the decommission process. If there is no decommission process because the subscriber is ad-hoc, don't use a durable subscription. Easier said than done, I know.

Notes
I can't be sure about this since I no longer work as part of the MQ product team, but I suspect that the new CAPEXPIRY feature was provided to address this issue. When IBM introduced MQ MFT (the product formerly known as FTE) the Explorer module used permanent dynamic subscriptions to collect file transfer job statuses. However, there were many cases i which the Explorer instance forgot it's subscription, people changed computers or jobs, or a thousand other reasons leading to abandoned subscriptions.

This is not an easily soluble problem for the MFT set of requirements. Favor user experience or favor efficient system usage, but not both. Now that we have CAPEXPIRY those subscription queues will eventually empty out on their own. I predict soon where will be a queue expiry for empty PERMDYN queues so we won't have a zillion abandoned empty queues lying around.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • Looks like IBM took down "Mission:Messaging: Easing administration and debugging with circular queues" and I could not find a replacement link, do you have a local copy you can post on your own blog? – JoshMc Feb 26 '19 at 15:34
0

Don't make it a durable subscription if there is a chance that the consuming application may never reconnect.

Roger
  • 7,062
  • 13
  • 20