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 IndexWebSphere Message Broker SupportWhat happens to messages after timeout on an MQGET?

Post new topicReply to topic
What happens to messages after timeout on an MQGET? View previous topic :: View next topic
Author Message
souciance
PostPosted: Thu Sep 21, 2017 12:04 am Post subject: What happens to messages after timeout on an MQGET? Reply with quote

Acolyte

Joined: 29 Jun 2010
Posts: 51

Hello,

We have request reply scenario where the IIB flow sends a message via its queue manager to another queue manager. The client then replies back using the correlationId.

In the same flow we use MQGET and set the wait interval.

My question is, what happens if the client replies after the wait interval is set? Will the message just be there on the queue but the MQGET will never read it? Or will it be thrown away to the queue manager dead letter queue?

Best
Souciance
Back to top
View user's profile Send private message
zpat
PostPosted: Thu Sep 21, 2017 12:50 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5515
Location: UK

It will just stay on the queue until something gets it or it expires (unless non-expiring).

It's normal to issue MQGET with WAIT and repeat that until you decide to stop the application.

Messages will be retained unless they are non-persistent and the QM is restarted.

Movement to the DLQ from a local queue will never occur automatically.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
souciance
PostPosted: Thu Sep 21, 2017 1:23 am Post subject: Reply with quote

Acolyte

Joined: 29 Jun 2010
Posts: 51

Thanks for the info.

I was a little bit afraid that the messages would remain on the queue. Yeah, we could set some expiry, the only problem with that is that we probably need be aware that the messages have been expired and it would make it harder to raise an alert or similar.
Back to top
View user's profile Send private message
zpat
PostPosted: Thu Sep 21, 2017 1:39 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5515
Location: UK

If the message is of no value after your get wait time limit, then the expiry of that message should be set to a value higher than this, but not infinite.

You can request a "report" message to be generated on message expiry.

You should be getting response messages by matching correlid, so that you don't pick up the wrong one (if one is left on the queue).

Personally, I like to set the expiry high enough that I can see if messages are being orphaned but not so high that they stay around forever.

However you must be selectively matching responses in this model.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
souciance
PostPosted: Thu Sep 21, 2017 2:22 am Post subject: Reply with quote

Acolyte

Joined: 29 Jun 2010
Posts: 51

Yeah we would be going for correlationId as the identifier. The problem is that the client application has a huge uncertainty in their response time. Even if we set some wait interval, there is a likelyhood that they might reply after the wait interval has expired. This would make it harder for us to detect unless messages are expired and a report is generated but I think that would make the solution more complicated than necessary for us. Most likely we will have redesign and simply revert to an MQInput and let them reply whenever it is possible.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Thu Sep 21, 2017 4:22 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1719
Location: Melbourne, Australia

It depends on the required QOS and the business value of the reply message.

If the reply contains critical data (eg. is used to update a DB that has downstream usage), the messages should be persistent and have no expiry. You then need to have a reconciliation process that periodically consumes all the reply messages that arrived after the wait interval exceeded on the original requestor.

If its not critical data, the reply messages could have a finite expiry (a few hours to days?), that allows monitoring and support teams to detect these aged messages.

If they have little value, use a low expiry that is a bit longer than what the requestor will wait. eg. Waits for 30 secs, Expires after 60 secs.

YMMV.
_________________
Glenn
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Message Broker SupportWhat happens to messages after timeout on an MQGET?
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.