SBL-EAI-04240: MQSeries Rollback Transaction failed: Queue Manager: '%1', Queue: '%2'rMQSeries Error Code: %3
Applies to:
Siebel System Software - Version: 7.5.3.6 [16186] - Release: V7
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.6 [16186]
Database: Oracle 9i
Application Server OS: IBM AIX 5L 5.1
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-2124433401.
Symptoms
Hi,
What happens when an inbound message is already dispatched to WF (using ReceiveSendDispatch method of the MQReceiver) and while the message is being handled, MQ queue mgr fails and both the response and inbound queues become unavailable. Siebel Transactions and Rollback on dispatch error properties are set, but in this case, the message could not be returned to the inbound queue, will it be lost? Or will the component somehow cache it?
Cause
xxxx
Solution
Message 1
For the benefit of other users, ReceiverMethodName was set to ReceiveDispatchSend for the MQ Series Server Receiver (MQSeriesSrvRcvr) and RollbackOnDispatchError and SiebelTransactions were set to True for the EAITransportDataHandlingSubsys. The customer wanted to know what happens if the response queue and the inbound queue become unavailable while a message is being processed by Siebel.
I carried out some testing. As part of this I created a workflow that waits for 3 minutes before returning a value. For the EAITransportDataHandlingSubsys RollbackOnDispatchError and SiebelTransactions are set to True. The MQSeriesServerSubsys is configured as follows:
MqPhysicalQueueName: TEST.QUEUE
MqModelQueueName: QM_eghtsgps06
MqRespPhysicalQueueName: TEST.QUEUE.RESP
The Default Persistence property of the queue was set to Not Persistent. I started a MQ Series Server Receiver (MQSeriesSrvRcvr) task and put a message onto TEST.QUEUE. The MQSeriesSrvRcvr task started to execute the workflow and while it was waiting I stopped the IBM MQSeries component service which provides startup and maintenance services for WebSphere MQ. In WebSphere MQ Explorer I noted that my queue manager shut down and the queues disappeared.
After 3 minutes the MQSeriesSrvRcvr task executed the remainder the workflow. The task then failed with an error and the log file included the following information:
[Continued]
Message 2
[Continued]
Sending Response (SBL-EAI-04239) Unable to put a message to MQSeries Queue 'TEST.QUEUE.RESP' Rolling back Siebel transaction Closed MQSeries Queue: 'TEST.QUEUE.RESP' (SBL-EAI-04240) MQSeries Rollback Transaction failed: Queue Manager: 'QM_eghtsgps06', Queue: 'TEST.QUEUE' Closed MQSeries Queue: 'TEST.QUEUE' Disconnected from MQSeries Queue Manager: 'QM_eghtsgps06'
(smisched.cpp 17(603) err=3500953 sys=0) SBL-EAI-00953: Call of Service 'SBL-EAI-00953: Call of Service 'EAI MQSeries Server Transport', Method 'ReceiveDispatchSend' failed: 32909', Method '(null)' failed: (null)
As you can see, the MQSeriesSrvRcvr tried to put a message on the response queue but of course it could not. RollbackOnDispatchError was set to True so it then tried to put the message back onto the queue (i.e. rollback the transaction) but again it could not.
I then restarted the IBM MQSeries component service. In WebSphere MQ Explorer I noted that my queue manager started up, the queues reappeared but the message that I put on the queue did not reappear.
I changed the Default Persistence property of the queue from Not Persistent to Persistent and repeated the test. Exactly the same thing happened as with the first test but this time when I restarted the IBM MQSeries component service the message reappeared. This is because the messages on the queue are now persisted.
[Continued]
Message 3
[Continued]
When I started another MQSeriesSrvRcvr task the message was picked up from the queue again and this time a message was correctly put on the response queue.
Testing showed that messages are not cached by Siebel. However, if a message cannot be put on the response queue Siebel will try to roll back the message to the original queue. Also, if the queue and the response queue are unavailable and the queue or a message put on a queue is persisted, the message is not lost and will be picked up again when everything is up and running.
Message processing takes place within a transaction which is similar to a database transaction. When a message is picked up from the inbound queue a transaction is started. After Siebel has processed the inbound message and put a message on the response queue, it will send a commit to MQSeries which will then remove the message from the inbound queue. The message will be not be removed until a commit is received.
- Siebel Technical Support
Keywords: MQ Series Server Receiver MQSeriesSrvRcvr ReceiverMethodName ReceiveDispatchSend RollbackOnDispatchError SiebelTransactions True EAITransportDataHandlingSubsys Inbound Response Queue Error Message MQSeries Default Persistence
Siebel System Software - Version: 7.5.3.6 [16186] - Release: V7
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.6 [16186]
Database: Oracle 9i
Application Server OS: IBM AIX 5L 5.1
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-2124433401.
Symptoms
Hi,
What happens when an inbound message is already dispatched to WF (using ReceiveSendDispatch method of the MQReceiver) and while the message is being handled, MQ queue mgr fails and both the response and inbound queues become unavailable. Siebel Transactions and Rollback on dispatch error properties are set, but in this case, the message could not be returned to the inbound queue, will it be lost? Or will the component somehow cache it?
Cause
xxxx
Solution
Message 1
For the benefit of other users, ReceiverMethodName was set to ReceiveDispatchSend for the MQ Series Server Receiver (MQSeriesSrvRcvr) and RollbackOnDispatchError and SiebelTransactions were set to True for the EAITransportDataHandlingSubsys. The customer wanted to know what happens if the response queue and the inbound queue become unavailable while a message is being processed by Siebel.
I carried out some testing. As part of this I created a workflow that waits for 3 minutes before returning a value. For the EAITransportDataHandlingSubsys RollbackOnDispatchError and SiebelTransactions are set to True. The MQSeriesServerSubsys is configured as follows:
MqPhysicalQueueName: TEST.QUEUE
MqModelQueueName: QM_eghtsgps06
MqRespPhysicalQueueName: TEST.QUEUE.RESP
The Default Persistence property of the queue was set to Not Persistent. I started a MQ Series Server Receiver (MQSeriesSrvRcvr) task and put a message onto TEST.QUEUE. The MQSeriesSrvRcvr task started to execute the workflow and while it was waiting I stopped the IBM MQSeries component service which provides startup and maintenance services for WebSphere MQ. In WebSphere MQ Explorer I noted that my queue manager shut down and the queues disappeared.
After 3 minutes the MQSeriesSrvRcvr task executed the remainder the workflow. The task then failed with an error and the log file included the following information:
[Continued]
Message 2
[Continued]
Sending Response (SBL-EAI-04239) Unable to put a message to MQSeries Queue 'TEST.QUEUE.RESP' Rolling back Siebel transaction Closed MQSeries Queue: 'TEST.QUEUE.RESP' (SBL-EAI-04240) MQSeries Rollback Transaction failed: Queue Manager: 'QM_eghtsgps06', Queue: 'TEST.QUEUE' Closed MQSeries Queue: 'TEST.QUEUE' Disconnected from MQSeries Queue Manager: 'QM_eghtsgps06'
(smisched.cpp 17(603) err=3500953 sys=0) SBL-EAI-00953: Call of Service 'SBL-EAI-00953: Call of Service 'EAI MQSeries Server Transport', Method 'ReceiveDispatchSend' failed: 32909', Method '(null)' failed: (null)
As you can see, the MQSeriesSrvRcvr tried to put a message on the response queue but of course it could not. RollbackOnDispatchError was set to True so it then tried to put the message back onto the queue (i.e. rollback the transaction) but again it could not.
I then restarted the IBM MQSeries component service. In WebSphere MQ Explorer I noted that my queue manager started up, the queues reappeared but the message that I put on the queue did not reappear.
I changed the Default Persistence property of the queue from Not Persistent to Persistent and repeated the test. Exactly the same thing happened as with the first test but this time when I restarted the IBM MQSeries component service the message reappeared. This is because the messages on the queue are now persisted.
[Continued]
Message 3
[Continued]
When I started another MQSeriesSrvRcvr task the message was picked up from the queue again and this time a message was correctly put on the response queue.
Testing showed that messages are not cached by Siebel. However, if a message cannot be put on the response queue Siebel will try to roll back the message to the original queue. Also, if the queue and the response queue are unavailable and the queue or a message put on a queue is persisted, the message is not lost and will be picked up again when everything is up and running.
Message processing takes place within a transaction which is similar to a database transaction. When a message is picked up from the inbound queue a transaction is started. After Siebel has processed the inbound message and put a message on the response queue, it will send a commit to MQSeries which will then remove the message from the inbound queue. The message will be not be removed until a commit is received.
- Siebel Technical Support
Keywords: MQ Series Server Receiver MQSeriesSrvRcvr ReceiverMethodName ReceiveDispatchSend RollbackOnDispatchError SiebelTransactions True EAITransportDataHandlingSubsys Inbound Response Queue Error Message MQSeries Default Persistence
תגובות
הוסף רשומת תגובה