WebSphere Message Brokers
File: ac12313_
Writer: Catherine Tucker

Task topic

This build: July 31, 2007 21:18:24

Avoiding thread starvation on fan-in flows

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.

In your Filter node, use an ESQL module, similar to the one shown below, 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.XMLNS.ComIbmAggregateControlNode IS NULL THEN
            RETURN TRUE;  -- wired to In
        ELSE
            RETURN FALSE; -- wired to Control
        END IF;
    END;
END MODULE;
Note: If you cannot 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 value of the Order Mode property on the advanced properties panel to be By Queue Order and select Logical Order. This frees up all of the configured additional instances to be used by the other MQInput node. Because the performance of the first MQInput node will be severely limited, use this configuration only 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
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:18:24

ac12313_ This topic's URL is: