This topic applies only 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 that are discussed here. 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. There is likely to be more traffic on the In terminal than the Control terminal of the AggregateReply node. Therefore, it is useful to have more threads running on the In terminal's input node. But it is not possible to configure this using two MQInput nodes. It is therefore possible for the AggregateReply node to be starved of threads, backing up reply messages and stalling the aggregation mechanism.
CREATE FILTER MODULE FanIn_Filter CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN IF Root.XMLNS.ComIbmAggregateControlNode IS NULL THEN RETURN TRUE; -- wired to In ELSE RETURN FALSE; -- wired to Control END IF; END; END MODULE;