aspose file tools*
The moose likes Websphere and the fly likes An MQ Trigger Problem Scenario Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » Websphere
Bookmark "An MQ Trigger Problem Scenario" Watch "An MQ Trigger Problem Scenario" New topic
Author

An MQ Trigger Problem Scenario

Srinivas Rao Marri
Greenhorn

Joined: Jun 07, 2006
Posts: 11
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?

Thanks
Srini
Chetan Parekh
Ranch Hand

Joined: Sep 16, 2004
Posts: 3636
This is not the right forum to post your problem.

Please choose apropriate forum from this list.


My blood is tested +ve for Java.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11406
    
  16

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
Guy Allard
Ranch Hand

Joined: Nov 24, 2000
Posts: 776
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: An MQ Trigger Problem Scenario