Avoiding thread starvation on fan-in flows

This topic only applies if the Control terminal of the Aggregate Control node in your fan-out flow is connected to output control messages to a queue. By not connecting the Control terminal you can overcome the issues discussed in this section. For further information about connecting the Control terminal of the AggregateControl see Using control messages in aggregation flows.

The Aggregate Reply node has two input terminals: In and Control. If you use both of these terminals, remembering that the use of the Control terminal is optional, the most efficient way to supply data to the Aggregate Reply node is to have a single MQInput node for the fan-in flow followed by a Filter node. The Filter node is used to route an incoming message to the In or Control terminals of the Aggregate Reply node as appropriate.

Use a single MQInput followed by a Filter node instead of two MQInput nodes in the message flow: one for the In terminal and one for the Control terminal. You should use a single MQInput node because there is no means of specifying how any additional threads (made available by the use of additional instances) should be distributed between the two MQInput nodes. Traffic on the AggregateReply node's In terminal is likely to be higher, therefore it is useful to have more threads running in its input node, it is not possible to configure this using two MQInput nodes. It is therefore possible for the node to be starved of threads, backing up reply messages and stalling the aggregation mechanism.

Use an ESQL module similar to the one shown below in your Filter node, to ensure that the messages are routed to the appropriate terminal of the AggregateReply node:
CREATE FILTER MODULE FanIn_Filter
    CREATE FUNCTION Main() RETURNS BOOLEAN
    BEGIN
        IF Root.XML.ComIbmAggregateControlNode IS NULL THEN
            RETURN TRUE;  -- wired to In
        ELSE
            RETURN FALSE; -- wired to Control
        END IF;
    END;
END MODULE;
Note: If it not possible for you to configure your fan-in flow as described above, you can force the MQInput node that is reading control messages to run single-threaded. Do this by configuring the MQInput node. Set the Order Mode property on the advanced properties panel to be By Queue Order and by selecting Logical Order. This frees up all of the configured additional instances to be used by the other MQInput node. Please note, because the performance of the first MQInput node will be severely limited this configuration should only be used if you have no alternatives.
Related concepts
Message flows overview
Message flow aggregation
Related tasks
Creating the aggregation fan-in flow
Creating the aggregation fan-out flow
Associating fan-out and fan-in aggregation flows
Setting timeouts for aggregation
Using multiple AggregateControl nodes
Handling exceptions in aggregation flows
Configuring aggregation flows
Related reference
AggregateControl node
AggregateReply node
AggregateRequest node