The MQeInput node takes unique 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 | Fail flow handles the error | Node retries | Not applicable | Not applicable |
Node propagates message to out terminal, exception occurs in out flow | Not applicable | Not applicable | Node retries then propagates to catch terminal | Node retries |
Node propagates message to catch terminal, exception occurs in catch flow | Fail flow handles the error | Node retries | Not applicable | Not applicable |
Node propagates message to failure terminal, exception occurs in fail flow | Not applicable | Not applicable | Node puts message to alternative queue | Node puts message to alternative queue |
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.
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 bridge 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.
Related concepts
Message flows
Related tasks
Handling errors in message flows
Managing errors in the input node
Catching exceptions in a TryCatch node
Using subflows
Creating a message flow
Defining message flow content
Related reference
Built-in nodes
WebSphere MQ Mobile Transport
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00413_ |