When you use aggregation flows, you might find that exceptions or database deadlocks occur. This topic tells you how to deal with them.
Before you start:
To complete this task, you must have completed the following tasks:
If an error is detected downstream of an AggregateReply node, the broker throws an exception. Another node in the message flow might also throw an exception using the ESQL THROW statement. In either case, when an exception is thrown, it is caught in one of two places:
The following table lists events and what happens to an exception thrown downstream of the AggregateReply node.
Event | Message propagated | Output terminal | Exception caught at |
---|---|---|---|
An expected reply arrives at the input node and is passed to the In terminal of the AggregateReply node. It is the last reply needed to make an aggregation complete. | Aggregated reply message containing all the replies | Out | Input node |
An unexpected reply arrives at the input node and is passed to the AggregateReply node. It is not recognized as a valid reply, and the Unknown Message Timeout property is set to 0. | Message received | Unknown | Input node |
A timeout occurs because all the replies for an aggregation have not yet arrived. | Aggregated reply message containing all the replies that have been received | Timeout | AggregateReply node |
An unknown timeout occurs because a retained message was not identified as a valid reply. | Retained message | Unknown | AggregateReply node |
An aggregation is discovered to be complete at some time other than when the last reply arrived. | Aggregated reply message containing all the replies | Out | AggregateReply node |
If you want to handle errors that occur in aggregation flows, you must catch these exceptions at all instances of each of these nodes in the message flow. To do this:
If you want a unified approach to error handling, attach the catch terminals of all these nodes to a single sequence of nodes, or create a subflow that handles errors in a single consistent manner and attach that subflow to each catch terminal.
The ESQL example below shows you how you can add an MQMD header and pass on the replies received by the AggregateReply node:
-- Add MQMD SET OutputRoot.MQMD.Version = 2; . -- Include consolidated replies in the output message SET OutputRoot.XML.Data.Parsed = InputRoot.ComIbmAggregateReplyBody; .
If you want to propagate the information about the exception in the output message, you must also set the Compute mode property of the Compute node to a value that includes Exception.
The AggregateRequest and AggregateReply nodes access the broker database to write and read information related to aggregated request processing in the table BAGGREGATE. Deadlocks can occur when multiple resources attempt to access database tables simultaneously.
To prevent database deadlock:
If this problem occurs, disable next key locking by typing the following in a DB2 command window:
db2set DB2_RR_TO_RS=YES
When this command completes, restart the DB2 database manager. This command does not have any other effect on the operation of this database.
If you are using another database, these deadlocks do not occur.
Related concepts
Message flows
Message flow aggregation
Related tasks
Configuring aggregation flows
Creating the aggregation fan-out flow
Creating the aggregation fan-in flow
Associating fan-out and fan-in aggregation flows
Setting timeouts for aggregation
Using multiple AggregateControl nodes
Handling errors in message flows
Designing a message flow
Creating a message flow
Defining message flow content
Related reference
AggregateControl node
AggregateReply node
AggregateRequest node
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac12340_ |