| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message lost when remote queue manager suddenly stops |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqusr |
 Posted: Thu May 16, 2019 9:36 am Post subject: Message lost when remote queue manager suddenly stops |
 |
|
Novice
Joined: 24 Feb 2018
Posts: 20
|
Hi,
We have 2 queue managers communicating with each other using sender/receiver channels.
We have a situation where the remote queue manager(2nd queue manager) goes down suddenly while the 1st queue manager is still sending messages to the 2nd. It has been observed that few messages that are being sent by the 1st QM when the 2nd QM goes down, are not being received. They are not stuck in transmission queue and are neither present in either of the dead letter queues i.e. they are getting lost.
While trying to replicate this in local system, I observed that when we change the heart beat interval of both sender and receiver channels from default 300 to a small value say 1,the message does not get lost and is present in transmission queue.
Is the message lost issue related to the heart beat interval or are we looking at the wrong place. Can there be any other cause of message being lost?
Any pointer would really help.
Regards,
mquser |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 16, 2019 9:50 am Post subject: Re: Message lost when remote queue manager suddenly stops |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqusr wrote: |
| Is the message lost issue related to the heart beat interval |
Not directly
| mqusr wrote: |
| Can there be any other cause of message being lost? |
The message being tagged by the putting application as not persistent.
If you fiddle with the heart beat interval you change the logic of the MCAs handshaking (and at a value of 1, completely contact admin the channel's performance!!) resulting in even non-persistent messages making it.
You should also check the setting of NPMSPEED as:
| Quote: |
| The disadvantage is that because they are not part of a transaction, messages might be lost if there is a transmission failure or if the channel stops when the messages are in transit. See Safety of messages. |
Basically if you want to ensure that messages are not lost (and there's endless debate in this forum about when message loss is acceptable) make sure the message are put as persistent so the software knows not to lose them.
And to pre-empt the usual suspects, that's not the same as setting the default persistence on the queue definition. It's called the default persistence because it's the one that's used if the application doesn't specify one. If the default is persistent, and the application specifies not persistent, the message is not persistent.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqusr |
| Posted: Thu May 16, 2019 10:19 am Post subject: |
|
|
Novice
Joined: 24 Feb 2018
Posts: 20
|
Thanks Victor.
As pointed, the local queue has been marked as persistent. However, will have to check if the application is setting the message as persistent before sending.
As for the heart beat part, as per my observation, when ever the remote queue manager would go down, the sender channel of QM1 was taking some time to identify that the receiver is down. As QM2 goes down, the IPPROC and OPPROC of the transmission queue continues to be 1. It is at this point when the sent message is lost. After a few seconds, when the transmission queue OPPROC and IPPROC goes to 0, the messages start piling up TX queue.
When the heart beat is reduced, the sender identifies that the receiver is down immediately, and hence the IPPROC and OPROC of TX queue goes to 0 almost immediately. Thus messages get piled in transmission.
Does setting the sent message to 'persistent' handle this situation as well?
Regards,
mqusr |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 16, 2019 10:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqusr wrote: |
| When the heart beat is reduced, the sender identifies that the receiver is down immediately, and hence the IPPROC and OPROC of TX queue goes to 0 almost immediately. Thus messages get piled in transmission. |
And the channel spends more time checking to see if the remote end is available than it does sending messages. This is a really, really bad idea. Especially if the "problem" isn't that the remote queue manager is down but just that the network blipped for a second or two.
| mqusr wrote: |
| Does setting the sent message to 'persistent' handle this situation as well? |
Yes.
As laid out in the "Safety of Messages" section of the link I posted, setting the message to persistent indicates that the message is not to be lost and will be preserved by the software in all instances (on a properly set up queue manager) up to and including a disc failure. The key difference in your scenario is the messages will not be removed from the transmission queue on QM1 until the receiver MCA confirms receipt and successful delivery (where successful delivery includes delivery to the dead letter queue).
This is fairly fundamental to MQ and well documented, but given how carefully you read my name:
| mqusr wrote: |
| Thanks Victor. |
I can see how you've missed it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqusr |
| Posted: Thu May 16, 2019 10:45 am Post subject: |
|
|
Novice
Joined: 24 Feb 2018
Posts: 20
|
 Sorry about that. Thanks Vitor! |
|
| 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
|
|
|
|
