| Author |
Message
|
| vivica12 |
 Posted: Wed Aug 05, 2009 11:59 am Post subject: MBR MQInput Node lost message when Transaction Mode=YES |
 |
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
We have a Message Broker flow using an MQInput Node with the Transaction Mode = ‘Yes’. The application putting to the input queue is doing this asynchronously. The messages being put to the queue are persistent, non-expiring messages.
We recently had a core dump in the execution group where this Message Broker flow resides. There were hundreds of messages being put the queue before/during/after this core dump and 12 messages were ‘lost’.
With the messages being persistent/non-expiring and the Transaction Mode being ‘yes’, we expected all messages would to be available on the queue (or possibly on the dead letter queue as no backout Q defined) after the core dump because messages currently being processed by the flow at the time of the core dump would not have completed the transaction, therefore the persistent message should not have been removed from the queue. This was not the case – messages were ‘lost’.
Are our expectations correct in that the messages should have rolled back? If not, where are we incorrect?
thanks
_________________
Vivica - signing off |
|
| Back to top |
|
 |
| WMBDEV1 |
| Posted: Wed Aug 05, 2009 1:58 pm Post subject: Re: MBR MQInput Node lost message when Transaction Mode=YES |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
Were the messages that were lost the ones that were being processed at the point in time the core dump occurred? Are you sure they didnt get processed at a later time (ie after the broker recovered from the core dump)?
What was the reason for the core dump? Did you raise a PMR to get this looked into?
Are you able to repeat this behaviour? |
|
| Back to top |
|
|
| vivica12 |
| Posted: Thu Aug 06, 2009 5:18 am Post subject: |
|
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
Yes we have a PMR opened about the core dump, but generally we don't get much feedback about core dumps and the dbx tools don't seem to be able to read the core on our local system. Not sure what will happen with this.
We know for sure that the messages never got processed as it was part of a controlled test and they knew how many went in, and what was supposed to come out. We believe the 12 were likley being processed when the core happened, but even in this case - should we have 'lost' them completely? There were msesages before and after the core that processed - once the EG recovered from core.
I guess we're just worried about the behavior, or maybe confused and hoping that what we expect is what is supposed to happen. With how we did the settings, if the message doesn't get processed it should roll back to the Q to get re-processed - correct?
_________________
Vivica - signing off |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 06, 2009 6:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you 100% sure that each and every message was Persistent?
Are you 100% sure that there is no point in your flow where you RETURN FALSE; or otherwise end the flow without propagating the message anywhere useful? |
|
| Back to top |
|
|
| vivica12 |
| Posted: Thu Aug 06, 2009 7:27 am Post subject: |
|
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
Are you 100% sure that each and every message was Persistent?
I asked the Cobol developer to verify this was as case. The code they are using is this: MOVE MQPER-PERSISTENT TO MQMD-PERSISTENCE. So yes, the messages are persistent.
Are you 100% sure that there is no point in your flow where you RETURN FALSE; or otherwise end the flow without propagating the message anywhere useful?
The last node in the flow is a compute node that does an insert into a database. At the end of this flow, we do a RETURN FALSE.
_________________
Vivica - signing off |
|
| Back to top |
|
|
|
|
