ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ API Support » triggering alternative?

Post new topic  Reply to topic
 triggering alternative? « View previous topic :: View next topic » 
Author Message
mqhack
PostPosted: Wed Nov 13, 2002 2:22 pm    Post subject: triggering alternative? Reply with quote

Newbie

Joined: 13 Nov 2002
Posts: 4

Due to a strange and unique combination of environmental factors, I need to create a triggering mechanism that runs within some Java code that I need to plug into a vendor package that we are currently integrating. I cannot use the standard triggering facilities that MQ has. What I would like to do is something like the following:
Create a MQ client program that opens a queue manager connection for browsing, then does a "get" using an unlimited wait, and the "browse_first" option. Anytime it gets a message returned, it needs to do an rmi call to another MQ process, but that one will run in bindings mode, and will read the messages off the queue with syncpoint control (and do database updates, XA transaction control (using the queue manager), etc all that fun stuff), then it returns to my calling MQ client program, which will go ahead and do another "get" with an unlimited wait, and the "browse_first" option, and the cycle starts again when another message arrives. Note that this client will also use the "fail if quiescing" option so as to not hang the queue. So this probably seems convoluted, but due to the constraints of the vendor package that we have, I would like to cobble together this "remote listener". Are there any actual problems that can be caused by running something like this? I assume that the triggering is going to seem like a cleaner and more simple implementation to everyone, but I can't use it. Any feedback, rants, whatever appreciated.

thanks
Gerry.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Nov 13, 2002 6:36 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Make sure your second MQ app that runs in Bindings mode can gracefully handle not finding any message on the queue (your client app finds a message but it expires before the 2nd app can get it).

Also, make sure your second app checks the MQMD_Backoutcount for each get, so you don't put yourself in a poisened message loop.

Other than that, right now, I can't think of any reason it wouldn't work.

Whenever it finds a message the client app will stop its get and call the 2nd app, and will only go back to the get with wait when control returns back to it? What if the bindings app bombs, and never returns control? You will never get retriggered?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqhack
PostPosted: Fri Nov 15, 2002 1:03 pm    Post subject: Reply with quote

Newbie

Joined: 13 Nov 2002
Posts: 4

Peter, thanks for your reply.
First of all, the queue I'm dealing with is persistent, so I don't think that message expiration should be a problem.

Could you please explain what a poisened message loop is?

Finally, you are correct in assuming that the second app does not return until it has finished any and all messages it finds on the queue, at which time it will return to the client who will then issue another "get". I'm counting on the client getting some sort of rmi exception if the second app goes down, but it probably makes sense to also externally monitor the depth on that queue just in case.

thanks
Gerry
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Sat Nov 16, 2002 6:26 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Expiry and Persistence are 2 completly seperate things. You can make a message Pesistent so it survives a Queue Manager restart, but that will do you no good if the message expires in the meantime. you can make a message never Expire, but that will do you no good if you make the message non-persistent and the queue manager dies while your message is on the queue.

So even if an app puts a persistent message that eventually ends up on your queue, it could expire before you get to it.

Poisened Message: A message is put on a triggered queue. The app gets triggered and does an MQGET on that message under syncpoint. As it is processing the message, the app abends because of the message content itself. Because the message was gotten under syncpoint, it is returned back to the queue. The app gets retriggered and goes to the queue to get the first message, which is that previous message. It picks up that same message, and it causes the abend again. Back to the queue the message goes. App gets retriggered, app picks up the same bad message, etc. You are in an endless loop, caused by a message. A bad message. A Poisened Message Loop.

Poisened Message Loops are only possible if the MQGET is done under syncpoint, cause otherwise the message is not returned to the queue when the abend occurs. Also, it must be the content of the message that is causing the error, rather than some other reason which may eventually clear itself up (database N/A or something like that).

Each time a message is returned to a queue after an MQGET done under syncpoint, the QM ups a field in the MQMD called the BackoutCount. Any app that gets messages under syncpoint should always check the value of the MQMD_BackoutCount after each and every Get. If the value is greater than some number, do something with this message besides your normal processing (which would cause an abend). Usually, the app will put the message to a second exception queue for later manual inspection. It is now free to go on with the rest of the messages that may be on the queue.

You can hardcode the values of the exception queue and the backout count count that will trigger your exception logic to kick in. Or, there are 2 attributes for every local queue called BackoutRequeueQName and BackoutThreshold. Now your MQAdmins can control what apps will do in this respect. The app needs to do an MQINQ call to read these 2 values before it can act on them.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqhack
PostPosted: Mon Nov 25, 2002 1:54 pm    Post subject: Reply with quote

Newbie

Joined: 13 Nov 2002
Posts: 4

Peter, thanks for the suggestions. I've got them coded up and it seems to work fine.

thanks again
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ API Support » triggering alternative?
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.