| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| How to investigate Message loss |
« View previous topic :: View next topic » |
| Author |
Message
|
| hari_k98 |
 Posted: Thu Dec 08, 2011 4:56 am Post subject: |
 |
|
Novice
Joined: 13 Jul 2007
Posts: 14
Location: India
|
Unfortunately the people are not taking absence of error as proof.
Basically looking to convince the other party I have successfully written to the MQ. |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Dec 08, 2011 7:53 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Look at their application logic. Work out why it is transactionally unsafe.
If you really want to look at API calls - run an API trace.
Or there is quite a nice support pac to do trace APIs using an exit, MA0W.
Then you can see the MQPUTs and MQGETs, and rather than guessing what might be going on. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 08, 2011 8:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Write your code to log out the MQRC of each MQPut, with an exact timestamp.
Every time they complain that you never sent a message, send them the current week's worth of these numbers, and ask them to explain which one of those MQRC 0's indicate a dropped message. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Dec 08, 2011 2:29 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
Unless you have obvious error messages in your MQ error logs - I would suggest that you stop wasting your time trying to find a mysterious (and fundamental) bug in IBM's software.
Instead look at the application. Almost every MQ application I have ever inspected has been written badly. Because people assume MQ is simple and fail to grasp the nature of transactional design. Presumably this is not taught at University. |
Agree. MQ does not "lose" messages. There is always a rational reason for why app messaging is not behaving as expected. The hard part is getting that reason, and 99% of the time it is an app problem with incorrect usage of MQ, and MQ will be working as designed. I have looked at many problems like this over more than 10 years.
I suggest that the application programs should log the date/time, message id, other useful MQMD fields, data and its length, for all puts and gets on the problem queue, or use an API Exit or MQ Trace. When there is a mis-match, look closely at the MQI options, MQMD values and data. The reason will then emerge.
From the OP description, it appears there are no MQ Channels involved. Is that correct?
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 08, 2011 3:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| hari_k98 wrote: |
1) Each being read by the application is stored in a database.
2) End user using one of fields in the message searches for the message.
3) They find a particular message is not in the database.
|
I've added numbers to help me understand the issue. This is confusing, and not very technically described.
1) By 'Each' you mean each message, yes? Is the message BROWSED in the queue? Or destructively read from the queue?
2) Where does the 'End user' search for the message? In the queue? Or in the DB?
3) This conflicts with 1) above, where you said that each message read by the app is stored in a DB. What are 'they' using to determine that a message is not in the DB?
What important clues have you left out of this?
This sounds more like a DB failure, and not an MQ problem.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
