| Author |
Message
|
| LouML |
 Posted: Fri May 19, 2017 12:47 pm Post subject: MQ Dropped message? |
 |
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
We're running MQ Server 8.0.0.2 in Linux VM.
An application group connects as a client (MQ Client 8.0.0.2).
They said they Put two messages to a QRemote yet only one made it to the other QMgr.
The first message at 14:51:30 and the second at 14:51:31.
I see the following timestamps:
The transmit queue on QM1 has a Last Get Time of 14:51:30 and a Last Put Time of 14:51:31
The sdr channel on QM1 has a Last Msg Time of 14:51:30
The rcvr channel on QM2 has a Last Msg Time of 14:51:30
The QLocal on QM2 has a Last Get and Last Put time of 14:51:30.
The message at 14:51:30 was successful.
The message that was Put at 14:51:31 is nowhere to be found.
Not in either Dead Letter queue.
No errors in the MQ logs for either queue manager.
Any ideas?
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri May 19, 2017 1:28 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
Why do you believe that the app successfully MQPUT two messages?
Is this a new app? Recently re-compiled?
Is a message in the transmission queue waiting to be sent? Display xmit queue qstatus and post the results here.
_________________
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 |
|
|
| LouML |
| Posted: Fri May 19, 2017 1:39 pm Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| bruce2359 wrote: |
Why do you believe that the app successfully MQPUT two messages?
Is this a new app? Recently re-compiled?
Is a message in the transmission queue waiting to be sent? Display xmit queue qstatus and post the results here. |
I don't believe it, but the App owner does. His app displays "message sent' in his log but of course it does NOT show MQ Reason Codes so I can't be sure.
There is nothing in the transmission queue
QUEUE(QX.QM2) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(0)
LGETDATE(2017-05-19) LGETTIME(14.51.30)
LPUTDATE(2017-05-19) LPUTTIME(14.51.31)
MEDIALOG( ) MONQ(HIGH)
MSGAGE(0) OPPROCS(1)
QTIME(30017, 30017) UNCOM(NO)
The app has been live for a few weeks with a very low volume. He said this happened last week as well.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| exerk |
| Posted: Fri May 19, 2017 2:01 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
In cases like this I fall back on a simple principle - prove to me that the message was actually put. Just because an app displays 'message sent' doesn't (for me) prove it.
Are the messages non-persistent? Is expiry set on the messages? Does the app use units-of-work? Do you have transaction monitoring? Is the NPMSPEED of the channel FAST? Is the RCVR set to NOT use the DLQ?
There are many factors that could lead to 'lost' messages and this would not be the first case of an app that happily reports RC=0 when CC!=0 etc.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 19, 2017 8:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
And remember if the message is not persistent it is acceptable to loose it in the channel if there is a communications problem. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat May 20, 2017 6:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Do an MQPUT under syncpoint.
Don't commit or backout.
Look at the Q Depth; look at the LastPutTime.
Now back out the unit of work, explicitly with a MQBACK or implicitly with an abnormal termination.
Review Q Depth and LastPutTime once more.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun May 21, 2017 6:27 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2527
Location: Melbourne, Australia
|
Can the issue be reproduced?
Consider running MQ trace.
If its a low volume channel, check the MSGS() attribute in the status. Watch for it to jump by 1 or 2.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Sun May 21, 2017 11:23 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5856
Location: UK
|
Use the new Application Activity trace feature to see the MQI calls.
_________________
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 |
|
|
| LouML |
| Posted: Tue May 30, 2017 3:52 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
As usual, we had to once again prove to an application owner that their application was the problem, not MQ.
http://www-01.ibm.com/support/docview.wss?uid=swg21660642
We used dmpmqlog and the dmpmqlog scraper to show them that their app was rolling back the messages in question.
Now, they confirm that they indeed had an issue and they're corrected it.
We'll see.
Thanks all!
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
|
|
