The MQInput node takes the following actions when it handles errors with persistent and transactional messages. Errors encountered with non-transactional messages are handled as described in Managing errors in the input node.
This action is summarized in the table below:
Error event | Failure terminal connected | Failure terminal not connected | Catch terminal connected | Catch terminal not connected |
---|---|---|---|---|
Node detects internal error | Flow connected to the Failure terminal handles the error | Message put to alternative queue; node retries if the put fails | Not applicable | Not applicable |
Node propagates message to out terminal, exception occurs in out flow | Not applicable | Not applicable | Flow connected to the Catch terminal handles the error | Node retries |
Node propagates message to Catch terminal, exception occurs in flow connected to the Catch terminal | Error logged, message rolled back | Error logged, message rolled back | Not applicable | Not applicable |
Node propagates message to Failure terminal, exception occurs in flow connected to the Failure terminal | Not applicable | Not applicable | Node retries | Node retries |
The node attempts retry processing when a message is rolled back to the input queue. It checks whether the message has been backed out before, and if it has, whether the backout count has reached (equalled) the backout threshold. The backout count for each message is maintained by WebSphere MQ in the MQMD.
You specify (or allow to default to 0) the backout threshold attribute BOTHRESH when you create the queue. If you accept the default value of 0, the node increases this to 1. The node also sets the value to 1 if it cannot detect the current value. This means that if a message has not been backed out before, it is backed out and retried at least once.
If a failure occurs beyond the Failure terminal, further retries are made until the backout count field in the MQMD reaches twice the backout threshold set for the input queue. When this limit is reached, the node attempts to put the message to another queue.
The message cannot be discarded, therefore the message flow continues to attempt to backout the message. It records the error situation by writing errors to the local error log. A second indication of this error is the continual incrementing of the BackoutCount of the message in the input queue.
If this situation has occurred because neither queue exists, you can define one of the backout queues mentioned above. If the condition preventing the message from being processed has cleared, you can temporarily increase the value of the BOTHRESH attribute. This forces the message through normal processing.
WebSphere MQ supports message groups. You can specify that a message belongs to a group and its processing is then completed with reference to the other messages in the group (that is, either all messages are committed or all messages are rolled back). When you send grouped messages to a broker, this condition is upheld if you have configured the message flow correctly, and errors do not occur during group message processing.
To configure the message flow to handle grouped messages correctly, follow the actions described in the MQInput node. However, correct processing of the message group cannot be guaranteed if an error occurs while one of the messages is being processed.
If you have configured the MQInput node as described, under normal circumstances all messages in the group are processed in a single unit of work which is committed when the last message in the group has been successfully processed. However, if an error occurs before the last message in the group is processed, the unit of work that includes the messages up to and including the message that generates the error is subject to the error handling defined by the rules documented here, which might result in the unit of work being backed out.
However, any of the remaining messages within the group might be successfully read and processed by the message flow, and therefore are handled and committed in a new unit of work. A commit is issued when the last message is encountered and processed. Therefore if an error occurs within a group, but not on the first or last message, it is possible that part of the group is backed out and another part committed.
If your message processing requirements demand that this situation is handled in a particular way, you must provide additional error handling to handle errors within message groups. For example, you could record the failure of the message group within a database, and include a check on the database when you retrieve each message, forcing a rollback if the current group has already encountered an error. This would ensure that the whole group of messages is backed out and not processed unless all are successful.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00414_ |