| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Unresolved transaction |
« View previous topic :: View next topic » |
| Author |
Message
|
| neeff |
 Posted: Sun Apr 25, 2004 6:53 am Post subject: Unresolved transaction |
 |
|
Novice
Joined: 06 Apr 2003
Posts: 11
Location: Munich and Ludwigsburg, Germany
|
Hi all,
yesterday I had a strange behaviour on my MQ 5.2 (CSD4) running on Solaris8.
A triggered queue (trigger priority set to 9) was obviously firing triggers in an infite loop (this is due to the design of the application, see below). Having a look at the queue showed me that around 5901 message are inside. Taking my application (a MQ<-> file adapter) looking to the queue showed me nothing (that means, the application did not recognize the set of messages as a file; expected was one large file).
I disabled the trigger and tried to clear the queue, but resulted in AMQ8143 ("queue not empty"). After short time of investigation, I tried to display mq transactions by running dspmqtrn and I got one transaction displayed. I then ran rsvmqtrn to resolve the transaction (used -a -c to commit); after that my application was able to recognize the set of messages as one file and afterwards I was able to spool out the messages using the application.
The file was sent to the queue by UTM (a transaction monitor used to retrieve data from a BS2000 system).
The application (the MQ<->file adapter) is designed to recognize the last message belonging to a file by means of the message priority. As soon as a prio9 message arrives, this indicates that a file has been completely spooled in.
Questions:
* In the described case, the it seems that the prio9 message had already arrived (the trigger was firing). How can it happen that the trigger began to fire without commitment of the last message? (I guess that the non-committed transaction was from the last messages belonging to the file).
* As the commit was done by rsvmqtrn manually and not by the application, is it possible that I have lost data (e.g., the file was not complete)? After I ran rsvmqtrn I checked the queue depth again and I saw 5921 messages. That also means that the trigger started firing before all messages have been spooled in to the queue.
Any help or experiences are highly appreciated. Thanks, Thomas
_________________
Thomas Neeff
Certified IBM System Administrator - WebSphere MQ, V5.3
Germany |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Mon Apr 26, 2004 7:25 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
* In the described case, the it seems that the prio9 message had already arrived (the trigger was firing). How can it happen that the trigger began to fire without commitment of the last message? (I guess that the non-committed transaction was from the last messages belonging to the file).
---Since i dont have the code here, i cannot really say what went wrong. But if you got a triggered message generated, that itself would mean that the message was committed. An uncommitted message would not generate a trigger message. So, i would go back and check the error logs to see if there were any errors. Also would check errors, if any, relating to runmqtrm.
* As the commit was done by rsvmqtrn manually and not by the application, is it possible that I have lost data (e.g., the file was not complete)? After I ran rsvmqtrn I checked the queue depth again and I saw 5921 messages. That also means that the trigger started firing before all messages have been spooled in to the queue.
---I am not 100% sure about rsvmqtrn, but i wouldnt expect it to loose any messages. Because the very purpose of it is to try and complete the transaction, which otherwise should have been completed by the app itself.
Cheers
Kumar |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 26, 2004 7:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Don't uncommitted messages still add to the queue depth?
So can't that cause the trigger to fire, even if the message isn't committed?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Mon Apr 26, 2004 7:43 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Jeff, you are right, uncommitted messages add upto the queue depth. But they dont cause a trigger message to be generated. From the manuals..
For non-shared local queues, the queue manager counts both committed and uncommitted messages when it assesses whether the conditions for a trigger event exist. Consequently an application may be started when there are no messages for it to retrieve because the messages on the queue have not been committed. In this situation, you are strongly recommended to consider using the wait option with a suitable WaitInterval, so that the application waits for its messages to arrive.
For local shared queues the queue manager counts committed messages only.
Of course, the assumption here is that you did *NOT* change the default queue definition and made it NOSHARE.
Cheers
Kumar |
|
| 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
|
|
|
|
