| Author |
Message
|
| souciance |
 Posted: Thu Sep 21, 2017 12:04 am Post subject: What happens to messages after timeout on an MQGET? |
 |
|
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 |
|
 |
| zpat |
| Posted: Thu Sep 21, 2017 12:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| souciance |
| Posted: Thu Sep 21, 2017 1:23 am Post subject: |
|
|
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 |
|
|
| zpat |
| Posted: Thu Sep 21, 2017 1:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| souciance |
| Posted: Thu Sep 21, 2017 2:22 am Post subject: |
|
|
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 |
|
|
| gbaddeley |
| Posted: Thu Sep 21, 2017 4:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
|
|
