MQSeries.net :: View topic - MQGet node leaving queue connection open?

chrisc · Posted: Tue Sep 22, 2009 3:06 am Post subject:

Hi everyone,

We're running Message Broker 6.1 on z/OS.

I have a couple of flows that are doing a couple of timer-based MQGets from a queue in order to offer a retry capability.

It's not specifically related to my question, but for background, this is the section of the flow in question:
- The basic flow has a request queue. If certain failures occur during processing it moves the message to a "hold" queue for retrying later.
- A TimeoutNotification node is set to fire a message every 10 minutes
- This is hooked up to an MQGet node that reads from a "hold" queue
- Out/warning is then hooked up to an MQOutput node that writes to a "retry" queue. This node is hooked back up to the initial MQGet, so it will loop as long as there are messages.
- The "no message" terminal on the MQGet node is hooked up to a second MQGet / MQOutput node combination that reads from the "retry" queue and writes the messages found to the flow's main request queue, looping until "no message" occurs.

This two-step process is so we can prevent retried messages zipping through and ending up on the "hold" queue while we're still processing them, which could result in infinite loops etc. We wanted to avoid using sentinel messages or message content flags to indicate the end of a run, hence the two queue approach.

...but anyway...!

This is all working nicely MOST of the time, but occasionally when I deploy this flow to the broker I get endless MQRC 2042 messages (object in use) indicating that the "hold" queue is in use by something. It generates a couple of messages per second, seemingly forever.

The only thing reading from this queue is this flow, which implies that the Broker is doing some sort of connection pooling thing and not releasing the connection when it's done.

Does anybody have any info about how this works?
How can we ensure that we don't get 2042 messages if we redeploy into an environment?
Can we force the MQGet node to close the connection after reading a message? Or can we explicitly close it after we've finished a retry run?

I'm thinking we might need to do something like remove the flow, wait till the connections expire (however long that is) then try again? It all seems a bit flakey. It's disappointing that the broker doesn't recognise that the flow being deployed is replacing the flow that used to have the connection to that queue open.

Any thoughts or insights would be appreciated. Sorry for the long post.

Many thanks
Chris