WebSphere Message Brokers
File: ac12320_
Writer: Catherine Tucker

Task topic

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

Setting timeouts for aggregation

You can use two properties of the aggregation nodes to set timeout values for aggregated message processing.

Before you start:

To complete this task, you must have completed the following tasks:

There are two situations that might require the use of timeouts:

  1. In certain situations you might need to receive an aggregated reply message within a certain time. Some reply messages might be slow to return, or might never arrive. For these situations:
    1. Switch to the Broker Application Development perspective.
    2. Open the fan-out message flow.
    3. Set the Timeout property of the AggregateControl node to specify how long (in seconds) the broker must wait for replies. By default, this property is set to 0, which means that there is no timeout and the broker waits indefinitely.

    If the timeout interval passes without all the replies arriving, the replies that have arrived are turned into an aggregated reply message by the corresponding AggregateReply node, and propagated to its timeout terminal. If you choose, you can process this partial response message in the same way as a complete aggregated reply message. If you prefer, you can provide special processing for incomplete aggregated replies.

  2. When a message arrives at the in terminal of an AggregateReply node, it is examined to see if it is an expected reply message. If it is not recognized, it is propagated to the unknown terminal. You might want the broker to wait for a given period of time before doing this, because:
    • The reply message might arrive before the work performed by the AggregateRequest node has been transactionally committed. This situation can be avoided by configuring the Transaction mode property of the Input node as described in Creating the aggregation fan-out flow.
    • The reply message might arrive before the control message. This situation can be avoided by leaving the control terminal of the AggregateControl node unconnected. For further information about the implications of connecting the control terminal, see Using control messages in aggregation flows.

    These situations are most likely to happen if you send the request messages out of syncpoint, and might result in valid replies being sent to the unknown terminal. To reduce the chance of this event:

    1. Switch to the Broker Application Development perspective.
    2. Open the fan-in message flow.
    3. Set the Unknown Message Timeout property on the AggregateReply node. When you set this property, a message that cannot be recognized immediately as a valid reply is held persistently within the broker for the number of seconds that you specify for this property .

    If the unknown timeout interval expires, and the message is recognized, it is processed. The node also checks to see if this previously unknown message is the last reply needed to make an aggregation complete. If it is, the aggregated reply message is constructed and propagated.

    If the unknown timeout interval expires and the message is still not recognized, the message is propagated to the unknown terminal.

Related concepts
Message flows overview
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
Avoiding thread starvation on fan-in flows
Using multiple AggregateControl nodes
Handling exceptions in aggregation flows
Designing a message flow
Creating a message flow
Defining message flow content
Using control messages in 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:25

ac12320_ This topic's URL is: