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 » WebSphere Message Broker (ACE) Support » What happens to messages after timeout on an MQGET?

Post new topic  Reply 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

Disciple

Joined: 29 Jun 2010
Posts: 169

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: 5849
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

Disciple

Joined: 29 Jun 2010
Posts: 169

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: 5849
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

Disciple

Joined: 29 Jun 2010
Posts: 169

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

Jedi

Joined: 25 Mar 2003
Posts: 2492
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 topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » What 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.