| Author |
Message
|
| mqbee1667 |
 Posted: Fri Jul 03, 2015 7:02 am Post subject: MQ messages are Lost |
 |
|
Newbie
Joined: 03 Jul 2015
Posts: 3
|
| We are moving our current MQ 6.5 to MQ 7.5. I am new to this environment. I am having an issue in new environment. When sender application is placing the Messages in the queue some of them are disappearing . This behavior is not consistent. Some times we receive all but some times we loose like 5 to 10 messages in a row and then we can find rest. My queues are Persistent Queues. When I bring down the queue manager and look at the active logs I can see all the messages including the missing ones with exact delivered time but those never showed up in the queue. Can some one shed some light on this behavior. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Jul 03, 2015 7:22 am Post subject: Re: MQ messages are Lost |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqbee1667 wrote: |
| My queues are Persistent Queues. |
As you'll see many times quoted in this forum, there are no such things as persistent queues. Persistence is a message attribute not a queue one. What you have are queues where the default persistence is true, but that doesn't mean the application can't deliberately set persistence false. Beware of this.
| mqbee1667 wrote: |
| When I bring down the queue manager and look at the active logs I can see all the messages including the missing ones with exact delivered time but those never showed up in the queue. |
Without compromising anything I said above, if the messages are showing up in the log (and that isn't the best way of checking) then it's likely a) the messages have their persistence set true and b) they are being delivered.
| mqbee1667 wrote: |
| Can some one shed some light on this behavior. |
What behavior? According to the MQ logs, the messages are being delivered. So on what basis do you claim that they "never showed up in the queue"? Is this because the receiving application doesn't record reading them, and if so how do you know this isn't an application problem? Are the messages, instead of being in the target queue, in a back out queue or dead letter queue because of processing problems? What steps have to taken, prior to posting here, to follow the progress of messages and track the "missing" ones? I'm thinking here of queue manager statistics and (for problem resolution purposes) COD/COA messages, but other methods are available.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqbee1667 |
| Posted: Fri Jul 03, 2015 8:12 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2015
Posts: 3
|
| Vitor ..Thank you for your quick reply. Before reading into the application , we are looking in the queue thru MQ explorer and finding that we are missing messages. Our source application is sending 200 (for example) but when we look at the queue we are seeing only 190. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 03, 2015 8:38 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqbee1667 wrote: |
| Vitor ..Thank you for your quick reply. Before reading into the application , we are looking in the queue thru MQ explorer and finding that we are missing messages. Our source application is sending 200 (for example) but when we look at the queue we are seeing only 190. |
If you don't have a reliable connection this is a fair assessment.
If the messages sent must be received make the messages persistent. Non persistent messages can be lost in the channel. (Interference, bad connection, etc...)
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 03, 2015 8:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqbee1667 wrote: |
| Our source application is sending 200 (for example) but when we look at the queue we are seeing only 190. |
And you've looked in the other queues for the missing 10 messages and not found them? And you've confirmed that the source application really did send 200 messages as it claimed? Are both applications using the same queue manager and, if not, what do the channel statistics say?
I'm assuming (because otherwise your question is nonsense) that none of these messages expire? And that nothing other than the application that processes these messages is reading the queue?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqbee1667 |
| Posted: Fri Jul 03, 2015 8:52 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2015
Posts: 3
|
I have looked in all the queues and not found any where. Yes I have confirmed that these messages are delivered by source application because we get ack back when the message is delivered.
No none of the messages are set to expire. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 03, 2015 9:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqbee1667 wrote: |
| Yes I have confirmed that these messages are delivered by source application because we get ack back when the message is delivered. |
So, to be clear here, what do you mean by this:
1) the source application sends some kind of acknowledgement to a request to send a message when the message is sent?
2) You receive a Confirmation Of Delivery from the IBM software?
If 1, then that does not prove a message has been sent - it just proves the application thinks it has sent it. Poor error handling would give you an ack when no message has been sent.
If 2, a COD message proves it's been delivered and these messages are being read off before you can examine the queue through the Explorer (as indicated by your earlier claim that the messages appear in the active log).
You might (out of politeness if nothing else) indicate if there's a channel involves as 2 of us have asked and you've not answered.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 03, 2015 9:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
If 2, a COD message proves it's been delivered ... |
Good so far.
| Vitor wrote: |
| ... and these messages are being read off |
COA would tell you that some app consumed a message.
Added for clarity to the OP.
_________________
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: Fri Jul 03, 2015 9:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
And before any of the regular readers start crowing, yes I got the confirmation message type mixed up. Again. If the OP was sending a message to a queue that was not being consumed (because it can be browsed with MQE) then it would be a COA messages not a COD. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 03, 2015 9:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Vitor wrote: |
If 2, a COD message proves it's been delivered ... |
Good so far.
| Vitor wrote: |
| ... and these messages are being read off |
COA would tell you that some app consumed a message.
Added for clarity to the OP. |
Too late  
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 03, 2015 9:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
COA would tell you that some app consumed a message.
Added for clarity to the OP. |
And trying to claw back some self respect, I did suggest the use of COD & COA messages earlier in this thread to check exactly what's happening...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 03, 2015 9:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
| bruce2359 wrote: |
COA would tell you that some app consumed a message.
Added for clarity to the OP. |
And trying to claw back some self respect, I did suggest the use of COD & COA messages earlier in this thread to check exactly what's happening... |
I knew you knew all that. Haste makes typos. Done there, been that. Not to worry.
Alles vergeben.
_________________
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: Fri Jul 03, 2015 9:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
Not to worry.
Alles vergeben. |
The Guilty Flee When No Man Pursues Them
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Jul 03, 2015 10:30 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Jul 06, 2015 3:21 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
If the MQPUT's show up in the recovery logs then the messages were persistent. Those logs will also show if the messages were transactional, and if so if the transactions were committed.
It's a little less trivial to match specific MQGET log records to specific MQPUT's, however it should be trivial to confirm from the recovery logs whether the number of messages removed from the queue matches the number of messages put to the queue (or whether the queue was purged), and whether any intran gets were not committed.
What do the CURDEPTH and UNCOM values of DISPLAY QSTATUS show ? |
|
| Back to top |
|
|
|
|
