| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| We found a (new) way of losing MQ Messages |
View previous topic :: View next topic |
| Author |
Message
|
| mikiu |
 Posted: Mon Feb 24, 2014 12:39 pm Post subject: We found a (new) way of losing MQ Messages |
 |
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Hello wise and gentle folks with an MQ interest; telling you this sad story just to feed your appetite for unusual facts on the MQ front; Scenario: messages properly put on a remote queue do not arrive to their destination without any indication of a malfunction.
z/OS app. puts message on a remote queue, queue manager is "M1" (not her real name), the message header carries remote queue manager "M2" on AIX where the target queue is also defined as a remote queue. We can see AIX "M2" properly placing message on the XMIT queue “M2-to-M3” and some messages DO arrive on the AIX queue manager "M3". The messages properly received have all a length < 5kB. We have found an incorrect setting of the MTU at the firewall level which caused messages of a length > 5kB not to arrive on the "M3" queue manager after the properly disappear from the XMIT queue ("M2"-to-"M3"). This is BAD and it took us a while to figure it out (great example of Morag’s classic “Where is your message?”).
My question is, how come there is no error message anywhere properly percolating to the MQ level that would alert us of this sad bad event. This bothers us to no end and our application developers are extremely upset when we keep saying "but MQ never does not lose no messages ever".
Just for you to know!
M.U. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Feb 24, 2014 1:15 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
You and your network folks might want to read this: https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/websphere_mq_channels_are_we_really_just_the_messenger?lang=en
The TCP/IP stack will drop frames that exceed the max MTU size you specify; but I'm surprised that 1) you received no TCP errors on either end of the channel, and 2) the MQ channel didn't fail due to the channel SEQWRAP fields mismatching.
You state that some of the messages disappear from the xmitq. Do the messages have a short expiry value?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 24, 2014 1:16 pm Post subject: Re: We found a (new) way of losing MQ Messages |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mikiu wrote: |
We have found an incorrect setting of the MTU at the firewall level which caused messages of a length > 5kB not to arrive on the "M3" queue manager after the properly disappear from the XMIT queue ("M2"-to-"M3"). This is BAD and it took us a while to figure it out (great example of Morag’s classic “Where is your message?”).
My question is, how come there is no error message anywhere properly percolating to the MQ level that would alert us of this sad bad event. |
If these were persistent messages travelling over a normal (not fastpath) channel I'd expect something in the channel logs and/or the messages to remain on the XMITQ.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 24, 2014 1:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| The TCP/IP stack will drop frames that exceed the max MTU size you specify; but I'm surprised that 1) you received no TCP errors on either end of the channel, and 2) the MQ channel didn't fail due to the channel SEQWRAP fields mismatching. |
Unless, as I've indicated, you've told the MCA it's ok to lose them.
| bruce2359 wrote: |
| You state that some of the messages disappear from the xmitq. Do the messages have a short expiry value? |
That's a good point.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mikiu |
| Posted: Tue Feb 25, 2014 6:31 am Post subject: |
|
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Thank you for your insight ... should've specified in my initial submission that I have no idea what the actual settings of remote queue, xmit queue and sender channel are at the external partner, but I am trying to determine that at this time (not a simple process with this particular player).
Thank you,
M.U. |
|
| 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
|
|
|
|
