|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
IBM best practices for handling message stagnation? |
« View previous topic :: View next topic » |
Author |
Message
|
JohnRodey |
Posted: Mon May 16, 2005 12:51 pm Post subject: IBM best practices for handling message stagnation? |
|
|
 Centurion
Joined: 13 Apr 2005 Posts: 103
|
Say we have a sending application that posts a message to a queue (REQUESTQ). This message has a correlation id defined so that another application on the other side knows that the request is to be handled by them. This sending application also stores off the message id of the message so that it may wait on another queue (RESPONSEQ) for its response. The receiving application on the other side, waits on a request, when received it does work and returns the result with the message id as the new correlation id.
I think this is a fairly common usage for WebSphere MQ.
If requests are being placed on the queue and not being serviced by the receiving side (either because there is no receiving application, or because the queues are being flooded with higher priority messages) we would like to take these messages off and place them back on with a higher priority.
One way that I found to do this is to use REPORT options. Although two issues come up when using report options to gain this functionality.
We set an expiry value, after that is reached the FULL DATA message is sent to the replyToQ.
Problem 1) If all expired messages are sent to the same replyToQ how would we know which queue to post them back to?
Problem 2) Messages can be put to replyToQ with the same correlation id, but not the same message id. We would then lose this message id and even if it were serviced the sending side would not know which response belonged to it.
Are there ways to still use the REPORT options method? Or is there another way to achieve this functionality that IBM suggests?
I know we can also create an application to browse these queues and check to see if messages have been on too long then bump up their priority. But this may be much unnecessary stress on the system since some messages may need a priority bump every .5 seconds. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon May 16, 2005 1:19 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I don't see where you have Problem 2 at all.
The original message ID should be in the report message, or the original message ID should be the correlation ID of the report message.
But generally, most people assume that if a request hasn't been replied to in X period of time, that it needs to be reissued. That is, the requesting application will decide that the Get has taken too long to get the right response, and then redo the request (possibly at a higher priority).
All this without using the Report options - just let the request or the reply expire. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon May 16, 2005 3:49 pm Post subject: Re: IBM best practices for handling message stagnation? |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
JohnRodey wrote: |
If requests are being placed on the queue and not being serviced by the receiving side (either because there is no receiving application, or because the queues are being flooded with higher priority messages) we would like to take these messages off and place them back on with a higher priority. |
If there is no app servicing the queue, then reputting the messages with a higher priority is a waste of time.
If you are going to reput the message with a priority bump every .5 seconds, you again are wasting resources. Just put the message with the right priority to begin with! MessageA is worth a priority of 5 at 12:00:00.00, but at 12:00:00.5, it is worth a priority of 9?!?! Just put it at priority 9 to begin with.
And use Expiry to get rid of irrelevant messages like Jeff suggested.
If your queue is constantly backed up with higher priority messages, then you should fix that performance problem first I think. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
JohnRodey |
Posted: Tue May 17, 2005 4:58 am Post subject: |
|
|
 Centurion
Joined: 13 Apr 2005 Posts: 103
|
Problem 2 does seem to be an issue because we cannot edit the correlation id of the original message, because the receiving side is waiting for a message with that correlation id. Also it seems that when the report message has gone to the "report queue", MQ creates a new message id for that message just like it would any message. So therefor the original message id seems to be lost.
Quote: |
If there is no app servicing the queue, then reputting the messages with a higher priority is a waste of time. |
We do not know if the service is out there listening or not. After a few bumps we will assume either the service is down and that message will be dropped.
Quote: |
If you are going to reput the message with a priority bump every .5 seconds, you again are wasting resources. Just put the message with the right priority to begin with! MessageA is worth a priority of 5 at 12:00:00.00, but at 12:00:00.5, it is worth a priority of 9?!?! Just put it at priority 9 to begin with. |
Assuming now that there are services out there waiting on these messages. We should try to deliver these messages. If a service is waiting on messages that can have priority of 0-9 then we obviously want to work the high priority messages first, but we also want to ensure that these lower priority messages are not being totally starved. Placing them on as a 9 from the start is not the functionality we are trying to achieve.
We also acknowledge that this functionality can be placed on the sending application which is another option, I was just curious to see if anyone knew a way to achieve this functionality using MQ report options.
Thanks for your posts! |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue May 17, 2005 1:34 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
I think you are going down the wrong path......
But, you could put a lower priority message onto the queue with an Expiry value and the Expiration report option set. If the reply is procecced in time, you get your reply. If the message instead expires, because higher priority message ahead of it are constantly being gotten, than an expiration report will be returned instead, and your sending app upon recieving that can reissue the request with a higher priority.
2 problems with this design - I am not sure an Expiration messages will be sent if a message expires, but is never actually "touched' for retrieval, because the app is clogged up above with higher priority messages. You will have to test.
More importantly, if there is no app servicing the queue, and the mesages expire, then you get no reply and no expiration report even when the message expires.
I would focus my efforts and improving the perfomance of the servicing app, so the queue is not constantly backed up. Or create a second lower priority queue with another instance of the app listening on that queue as well. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|