| Author |
Message
|
| bf1967 |
 Posted: Thu Apr 18, 2002 10:33 am Post subject: |
 |
|
Newbie
Joined: 17 Apr 2002
Posts: 3
Location: Bob Fox
|
I have an application(A) that needs to put a request on a queue, Another application(B) will read this message and do some processing and put the reply on the queue specified by (A). Appl (A) will wait for a specified period of time for a response from (B) (based on correlationId). If (A) times out, it will go about it's business. It is still possible for (B) to put a reply on the queue. Since (A) isn't looking for these replies anymore there will be a bunch of stranded messages. I don't want to loose those messages. I want to more them to a different Q. Is there an easy way to do this thru MQ without writing an app to sift through messages which exist past the timeout value? Any thoughts? TIA
Bob Fox |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Apr 18, 2002 11:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Have AppA get any and all message from the reply queue. Once it has the message, examine it to see if it's CcorrelID matches the CorrelID of the reply you want. If it does, process normally. If no match, this message can then be put to your "RecycleBin" queue. Repeat until no more messages on queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu Apr 18, 2002 11:52 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
if you have set an expire time then when those message's hit that threshold they are gone
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Apr 18, 2002 8:26 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Peter,
It's a bit more complicated than that. If he sets up Application A to get all messages from the queue, they will actually occur in 3 conditions:
1) The correlId matches the correlId you're looking for, in which case you process the message.
2) The correlId's do NOT match, but this message was put to the queue within the "timeout" period (this is not the expiry value obviously, but it is the timeout that Application A had on its MQGETs BEFORE we modified Application A to now grab all messages from the queue) in which case we should probably put it back on the queue we just got it from.
3) The correlId's do NOT match, but this message has been sitting on the reply queue past its "timeout" period, in which case we put it to the recycle bin queue.
Obviously, this has the drawback that you're gonna be doing alot of PUTs because you'll end up putting quite a few messages back on the original reply queue (depending on the rate at which replies are coming in). Personally, I think the original idea, having some other application that simply moves old messages to a recycle bin queue while Application A is matching CorrelIds on its MQGETs is the way to go. Either that or increase the wait interval on Application A's MQGETs such that you don't run into this problem to begin with...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 19, 2002 4:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
| 2) The correlId's do NOT match, but this message was put to the queue within the "timeout" period (this is not the expiry value obviously, but it is the timeout that Application A had on its MQGETs BEFORE we modified Application A to now grab all messages from the queue) in which case we should probably put it back on the queue we just got it from. |
If the message is put within the timeout period, wouldn't appA be there already, doing its Get-with-wait-for-specific-correl-ID? (I am making the assumption, maybe incorrectly, that AppA waits on the queue for the duration of the timeout period. If that is 5 seconds, and AppA waits 5 seconds, and the reply comes back in 5.1 seconds, this message must now go to the recyclebin queue)
So AppA puts a message and waits for a specific reply. If it gets it great, if not it ends. AppA is triggered on first. Any late replies will trigger it to go drain the queue of old messages. If late replies arrive while AppA is waiting for a specific reply, AppA will be triggered when it closes the queue and the QM sees that there more messages there.
_________________
Peter Potkay
MQSeries Certified Specialist,Developer
[ This Message was edited by: PeterPotkay on 2002-04-19 06:00 ] |
|
| Back to top |
|
|
| bf1967 |
| Posted: Fri Apr 19, 2002 6:31 am Post subject: |
|
|
Newbie
Joined: 17 Apr 2002
Posts: 3
Location: Bob Fox
|
| Unfortunately App(A) is rather limited in what it can do with MQ messages (It is a Siebel MQ Adaptor). It is implemented such that it will send out a request and wait for a reply. The timeout is needed because there is a user waiting for a response, otherwise it wouldn't be needed. It will wait on the Q looking for the matching correlationid for the full timeout. There hopefully will not be many situations where we do timeout, but I do need to cover them. My initial approach was to write a separate app to do the cleanup/moving of all the messages. I wanted to make sure that there was not an easy way to do this within MQ itself. I thought that there might be a way to get expired messages sent to another Q. I wasn't able to find anything like that in the MQ docs, but then again there are a LOT of docs. Thanks to everyone who responded for their time and advice. If you have any other ideas I would like to hear them. |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Apr 19, 2002 10:04 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Peter,
You correctly describe the original situation where we are doing MQGETs matching against CorrelId. However if we implement the solution you were mentioning where we no longer match against CorrelId (and get all messages from the queue) there is no need to set a timeout on Application A's GETs (it can have an infinite wait)... In such a case, we need to do 3 different things depending on the state of the message we actually retrieve from the queue...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 19, 2002 10:34 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
hmmm, I'm gonna keep going with you on this because I am considering something similiar for a future project's design, and if it's doomed to fail, I wanna know now! 
AppA will have the capability to do 2 different kind of GETs. The first GET will be with a 5 second wait, for a specific ID, for only one message. This path would occur only if the user started the process, i.e. they dropped a request message.
The other GET path does a get for any message, no wait and read until 2033. This path only executed if AppA was triggered by MQ. Either by a late reply arriving when all is quiet (AppA is sleeping), or if a late reply arrives while AppA is waiting its 5 seconds on another current reply. In the latter, when AppA closes the queue (whether it gots its reply or not), triggering will occur to tell it to go back and clean up.
Any messages arriving after 5 seconds are considred old, but not throwaway.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Apr 19, 2002 10:46 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Peter,
What you just described is different from the initial post you made:
| Quote: |
| Have AppA get any and all message from the reply queue. Once it has the message, examine it to see if it's CcorrelID matches the CorrelID of the reply you want. If it does, process normally. If no match, this message can then be put to your "RecycleBin" queue. Repeat until no more messages on queue. |
When I read that post, it didn't say anything about doing two different kinds of GETs, which is why I responded the way I did. Now this method you are describing in your last post, may work, but I don't understand what you mean when you say that the application will take the second path if it is "triggered by MQ. Either by a late reply arriving when all is quiet (AppA is sleeping)" If AppA is sleeping, that means it is still actually running, in which case it can't be triggered. Unless you are referring to triggering another instance of AppA?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 19, 2002 11:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Yes, sorry, I wasn't clear enough originally on the fact that there are 2 different paths in the program for GETS.
And "sleeping" was probably a bad term. I meant completly shut down, ready to be triggered.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sdpls |
| Posted: Thu Apr 25, 2002 8:23 am Post subject: |
|
|
Newbie
Joined: 24 Apr 2002
Posts: 1
|
| Quote: |
On 2002-04-18 11:33, bf1967 wrote:
I have an application(A) that needs to put a request on a queue, Another application(B) will read this message and do some processing and put the reply on the queue specified by (A). Appl (A) will wait for a specified period of time for a response from (B) (based on correlationId). If (A) times out, it will go about it's business. It is still possible for (B) to put a reply on the queue. Since (A) isn't looking for these replies anymore there will be a bunch of stranded messages. I don't want to loose those messages. I want to more them to a different Q. Is there an easy way to do this thru MQ without writing an app to sift through messages which exist past the timeout value? Any thoughts? TIA
Bob Fox
|
Could a solution to this be to request an Expiry report message with full data to be sent to a reply-to-queue set by application B, in the event of application A 'going away' before Application B replies to its request. A suitable expiry time (just longer than the wait time of appl A?) would have to be set by Appl B.
Phil.
|
|
| Back to top |
|
|
| oz1ccg |
| Posted: Fri Apr 26, 2002 9:13 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
| Quote: |
Could a solution to this be to request an Expiry report message with full data to be sent to a reply-to-queue set by application B, in the event of application A 'going away' before Application B replies to its request. A suitable expiry time (just longer than the wait time of appl A?) would have to be set by Appl B. |
Might do the trick ... 
A typical way of handling this situation with what i call "mother less" messages it to have an program that's emptying the queue now and then, to get rid of old messages. The only problem is to learn it to let "un-expired" messages sit in the queue for the requester. One way to use the browse option and then "get under cursor" if it's expired...
I hope it's not out of topic.
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 26, 2002 9:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
One way to use the browse option and then "get under cursor" if it's expired...
|
A get will never return an expired message. It will be discarded.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Apr 26, 2002 11:02 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I think that's exactly what he's suggesting though. If you have a queue with 10 messages, 3 of which are expired, and you those 3 expired messages to be removed, you simply browse the entire queue. By "touching" the 3 expired messages they will be removed, and the other 7 will still be on the queue because you were only browsing it. So the curdepth always reflect the number of unexpired messages on the queue, in this case 7.
But I think that such a thing is unnecessary. You don't have to worry about the queue depth continuing to increase because of expired messages. Here's why. Since messages are delivered to the queue in FIFO order, the oldest messages will be closest to the front of the queue. Although your application is doing an MQGET for a specific message, to find this message, the queue manager needs to scan the queue, starting from the front. And any expired messages it encounters during its search will be automatically removed. So over time, you'll always end up getting rid of all the expired messages.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Sat Apr 27, 2002 11:02 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Hi,
| Quote: |
One way to use the browse option and then "get under cursor" if it's expired...
A get will never return an expired message. It will be discarded.
|
Yes, it's right if we're using expiery on the messages, but in the explenation it should be an logical expiery, so the messages would stay in the queue until my cleanup program runs and moves those "pseudo expired" messages to let's say a database whatever. It depends of what type of data we're dealing with...
If you allows messages to expiery phisical just let them go.... If not you have to keep track of them, thats what I tried to explain...
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
|
|
