CODEWITHSUNDEEP
ibm-mqmessagebroker
spakendralo man
spakendralo man

Reputation: 665

WebSphere MQ and IIB: Events potentially fill up the queue manager

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

Upvotes: 2

Views: 594

Answers (2)

T.Rob
T.Rob

Reputation: 31832

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.

Upvotes: 2

Roger
Roger

Reputation: 7456

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

Upvotes: 0

Related Questions