| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Expiry In General |
« View previous topic :: View next topic » |
| Author |
Message
|
| pingisi |
 Posted: Thu Jan 23, 2003 10:41 am Post subject: Message Expiry In General |
 |
|
Newbie
Joined: 23 Jan 2003
Posts: 2
|
I'm trying to understand the expirty message option. We have a Java client that Puts a message to the requestQueue. Our CICS backend Trx then pulls the message from the queue, processes it and puts the repsonse out the reposonseQueue. The Java waits for a response and matches on msgId. We set an expiry on the requestMessage going up, however we are seeing numerous responseMessges sitting on the responseQueue due to either unmatched messages or timeouts. How can we clean thes messages up? 
Thanks in advance and I appologise for the long post. |
|
| Back to top |
|
 |
| bduncan |
| Posted: Thu Jan 23, 2003 3:42 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
It seems to me that if you are setting an expiry on the request message, it should not be causing reply messages to be piling up on the reply queue. When you send the request, the processing application has a certain amount of time to MQGET the message before it expires. If it expires, then the processing application will never get the request message, and therefore never process it and create a corresponding reply message. If it does get the request message before it expires, it will process it and create a reply message and MQPUT it to the reply queue. Therefore, it sounds like your problem is more likely due to one of two things:
1) You are setting a wait time in the requesting application when it does the MQGET for the reply message. If the wait interval is exceeded before the reply message gets put to the reply queue, then the requesting application will stop waiting for it and move on to the next request. As soon as it stops waiting, the reply message may arrive, but nobody is watching for it anymore, so it'll simply sit there.
2) The MsgId of the reply message doesn't match what the requesting application is looking for, perhaps because the processing application isn't always setting it correctly. Which begs the question, why are you using MsgId to match against on the reply messages? Typically the request/reply paradigm uses the CorrelId field instead. That is, you send a request message with some MsgId and no CorrelId. The reply message is constructed with a new and different MsgId (since it is afterall a different message) and the CorrelId is set to the MsgId of the request message.
As far as cleaning the messages up, you never mentioned whether or not the reply messages also have an expiry. Whether they've expired or not, the only way to remove them from the queue is either to clear the queue via runmqsc, or write another application which repeatedly does MQGETs on the queue without matching against any parameters. If the messages have expired, then the MQGET will cause them to be "touched" which means the queue manager will actually remove them since they have been expired. If they don't have an expiry, then the MQGET will remove them from the queue.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| pingisi |
| Posted: Fri Jan 24, 2003 2:51 am Post subject: |
|
|
Newbie
Joined: 23 Jan 2003
Posts: 2
|
Brandon,
Thanks so much for the quick response. The problem is that our requestMessage has no expiry on it. We have an application that poles the mainframe back-end to do a simple data fetch, however if the mainframe is down (due to batch processing) that message sits in the request queue until the backend comes up. Then all the messages get processed and then consequently sit on the responseQueue. So, with all that said, we will be setting an expiry on the requestMessage so that when the backend does come up and the CICS trx does the MQGET, it will clean out the expired messages.
Unfortunately, this is happening at a client's site so we are extremely limited as to what we can see. We go on faith as to what they tell us. And they mis-informed us. Thank you very much for your quick response.
 |
|
| 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
|
|
|
|
