| Author |
Message
|
| tkaravind |
 Posted: Sat Jun 24, 2006 4:22 am Post subject: Can uncomitted messages cause Triggering ? |
 |
|
Acolyte
Joined: 24 Jul 2001
Posts: 62
|
Hello All,
We are facing a strange problem in our Production environment - Application seem to be triggered when there are no messages in the queue - resulting in a large number of failures as the triggered app;ication cannot find the message !
There is a strong suspicion that this might be due to the triggering happening even when messages have not been committed by the channel involved .
In this case the messages are output by a message flow across a cluster queue manager.
And there are two Broker queue managers putting messages across to the clustered target.
They could be at any point sending messages at the same time.
Has anyone experienced this situation before and can throw some light on the same ?
Many Thanks,
Aravind |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sat Jun 24, 2006 6:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Aa application message lands on a triggered application queue under syncpoint. The trigger message is not created AND committed to the INIT queue until the application message is either commited ***OR*** rolled back.
So you might get triggered for an application message that was rolled back and no longer there. This is by design specifically for Trigger On First queues, where App Message #1 and #2 land. #1 causes the trigger conditions to be true (q depth goes from 0>1) and #2 lands right after. #1 gets rolled back. Q depth goes from 2 to 1. If the trigger message generated by #1 also got rolled back, the app q would find itself with a message on it and no trigger (remember, app message #2 did not make the q go from 0 to 1).
| Quote: |
Application seem to be triggered when there are no messages in the queue - resulting in a large number of failures as the triggered app;ication cannot find the message !
|
This is not cause for concern! Any properly written MQ app that is triggered should code for and expect the occasional 2033 MQRC.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Sun Jun 25, 2006 11:51 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| So you might get triggered for an application message that was rolled back and no longer there. |
I do not think so.
The trigger msg is put in the same unit of work as the app msg, so it is not possible for an app msg to be rolled back and the trigger msg to remain.
In Peter's scenario. the app cannot roll back #1 and not #2.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Jun 26, 2006 5:46 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
I have done a lot of triggering, but haven't done a lot of backing out of messages, so I honestly don't know what the story is here. Someone please find out, as I'm very interested too!
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 26, 2006 5:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
How many queue managers are in the receiving cluster? What is the distribution of messages (e.g. round robin)?
What trigger are you using?
Also (out of morbid curiosity) why do you consider a 2033 a failure? In most MQ apps it's a relief because you've emptied the queue and can go home?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Jun 26, 2006 6:04 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
on z/OS (and maybe on other plattforms too) the trigger is created while the message that caused the trigger is still in commit phase. if triggering and application start is fast it may occur that the triggered application gets 2033 - no message available because commit of the message has not finished yet.
i saw this situation quite a few times (last time i saw it was last week).
this is also described in the documentation:
Application Programmers Guide
Chapter 14 - Starting Webpshere MQ applications using triggering
"Conditions for a trigger event" - Point 3
| Quote: |
| a. 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. |
_________________
Regards, Butcher |
|
| Back to top |
|
|
| tkaravind |
| Posted: Mon Jun 26, 2006 7:52 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001
Posts: 62
|
Thanks everyone.
I have seen the following happening in this case :
When messages start coming thru the cluster channels - the triggered application starts and waits ( for 120 secs ) ... In this meantime messages keep coming through cluster channels ... For some reason the application is unable to read these messages ...and it just comes out after 120 secs and creates an empty file ! (The application converts messages to files)
This is strange as the Batch size for the cluster channel is defined as 50 ...So even if the triggering happens for uncommitted msgs ... after 50 msgs arrive they shud get committed and be available to the application.
This is not happening - Am I missing something here - do the Channels not commit using the Batch size in someway ? If so - what would be the process by which the channel commit happens ?
And is there a way I can count the Uncommitted messages coming over a channel process ?
As I said earlier - the suspiscion is on the two Broker servers connecting through the cluster simultaneously - can this really cause a problem ?
Regards,
Aravind |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Jun 26, 2006 8:53 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Nigelg wrote: |
| Quote: |
| So you might get triggered for an application message that was rolled back and no longer there. |
I do not think so.
The trigger msg is put in the same unit of work as the app msg, so it is not possible for an app msg to be rolled back and the trigger msg to remain.
In Peter's scenario. the app cannot roll back #1 and not #2. |
Sorry Nigel, from the APG:
| Quote: |
If all the above required conditions are met, and the message that caused the trigger condition is put as part of a unit of work, the trigger message does not become available for retrieval by the trigger monitor application until the unit of work completes, whether the unit of work is committed or, for trigger type MQTT_FIRST or MQTT_DEPTH, backed out.
|
_________________
-wayne |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Jun 26, 2006 11:11 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| ... after 50 msgs arrive they shud get committed and be available to the application. |
As I understand it messages will only get committed if the putting application commits them. The channel may send them but they don't appear until the application commits them.
Of course I could be wrong.  |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Jun 26, 2006 11:26 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| kevinf2349 wrote: |
| Quote: |
| ... after 50 msgs arrive they shud get committed and be available to the application. |
As I understand it messages will only get committed if the putting application commits them. The channel may send them but they don't appear until the application commits them.
Of course I could be wrong. |
Kevin, there's really *two* commits here...one when the application commits the messages, thus making them available for the channel to move them off the xmitq, and one when the channel commits the batch (or portion of) of messages, which would make a trigger message available.
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 26, 2006 3:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| wschutz wrote: |
| Nigelg wrote: |
| Quote: |
| So you might get triggered for an application message that was rolled back and no longer there. |
I do not think so.
The trigger msg is put in the same unit of work as the app msg, so it is not possible for an app msg to be rolled back and the trigger msg to remain.
In Peter's scenario. the app cannot roll back #1 and not #2. |
Sorry Nigel, from the APG:
| Quote: |
If all the above required conditions are met, and the message that caused the trigger condition is put as part of a unit of work, the trigger message does not become available for retrieval by the trigger monitor application until the unit of work completes, whether the unit of work is committed or, for trigger type MQTT_FIRST or MQTT_DEPTH, backed out.
|
|
In my scenario, (Triggr OnFirst) AppA is putting message #1 under syncpoint, trigger message is created but not committed, AppB puts message #2 to the queue, AppA rolls back its message #1, the trigger message (as a result of message #1) is committed, and the app is triggered and finds message #2.
Without this design of committing trigger messages even if the triggering app message is rolled back, message #2 would be stranded on the queue because there would not be a trigger message created from message #2 landing on the queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Jun 26, 2006 11:52 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Thanks guys, I missed that!
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
