I have two queue managers(qm1, qm2), one among them(qm2) is remote.
I have trigger associated with my qm1 queue, which will put messages directly to the qm2 queue.
In this scenario, if qm2 gone down, and message came to qm1 queue. Trigger will fire and try connecting to qm2. It will fail. Then the message will backed out the same queue i.e qm1 queue.
Now qm2 is up. But the message wont be consumed from qm1 queue. If a second message comes then only the previous message will also consumed as all together. If second message wont come for one week my first message will held up in the queue. Which is not a right behaviour.
In IBM MQ API is there any way to handle this situation?
Chetan is right. This forum is for asking questions about this site, bringing issues to the moderators attention, and so on. Questions about technologies belong in the other forums. This one possible belongs in General Computing, or possibly IBM Websphere...
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Have you talked to your MQ system admins about ways to solve this?
Seems to me like you need to have your MQI consumer/getter on qm2 fired unconditionally during qm2 restart, to consume whatever is on it's input queue. In the case of a restart, your getter code may need to wait a little longer for messages. The channels have to get fully operational, and time is needed to get the message(s) off of qm1's transmit queue.
But you might need no code changes, just the admin setup to fire your qm2 consumer during system restart.
Guy [ January 09, 2007: Message edited by: Guy Allard ]