See information about the latest product version
Considering performance for timeout flows
When you design timeout flows, the decisions that you make can affect the performance of your brokers and applications.
You can use the timeout nodes TimeoutControl and TimeoutNotification in your message flows to control the way in which your message flows operate:
- Set the Operation Mode property
of the TimeoutNotification node
to Automatic. This setting causes
a flow to be invoked at the interval that you specify in the Timeout Value property. If the downstream
processing is intensive, and the flow is still busy when the next
timeout occurs, the flow is not started for that timeout instance.
The flow is notified to start again only if it is free when a particular
timeout occurs.
The value of the Additional Instances property of the message flow is ignored downstream of a TimeoutNotification node, and you cannot use this property to change the behavior of the flow.
- Use two associated flows to perform user-defined timeout processing.
Set a timeout with a TimeoutControl node,
and notify the flow using a TimeoutNotification node (which
behaves like an input node to start a new message flow thread). If
the downstream processing from the TimeoutNotification node is
significant, requests that are set up in the TimeoutControl node can build
up. You can specify that the timeout messages are generated only when
the flow that starts with the TimeoutNotification node becomes
free again.
You cannot increase the Additional Instances property of the message flow if it starts with a TimeoutNotification node, therefore you cannot apply more threads to increase the capacity of the flow.
Although you can use a TimeoutNotification node to cause nodes in a message flow to poll for the next item of work, this approach forces a delay between each transaction, and typically does not provide an efficient solution. If you want to periodically check a resource for the next piece of work, and process it immediately, consider one or more of the following alternative solutions:
- Use a built-in input node.
- Write your own input node by using the user-defined node API (in Java™ or C).
- Consider purchasing an IBM® or vendor-provided adapter which polls the subsystem you want, and triggers the flow.
A message flow that uses these options can process more work overall than it can if you implement a timeout solution, and incurs lower CPU cost, although your initial development costs might be slightly higher.