A TimeoutControl node is associated with a TimeoutNotification node by both nodes being configured with the same Identifier. The ControlledTimeout sample shows that more than one TimeoutControl node can be associated with one TimeoutNotification node. This scenario means that you can update or cancel timeout requests processed through one TimeoutControl node by using any of the other TimeoutControl nodes that are associated with the same TimeoutNotification node.
If you want to try this scenario, the simplest method is to edit the cancellation .mbtest files, which writes them to the other input queue so that they are processed by the other node. A more advanced option is to change the AllowOverwrite field in the timeout request to TRUE, which means that the TimeoutControl node discards the currently running timeout request in favour of the new incoming one (as matched by the Identifier tag in the timeout request itself). You can also create new timeout request messages with different timeout identifiers to test the processing of multiple concurrent timeouts.
In the sample, the timeout request is contained in the body of the message. It is possible for it to be passed anywhere in the message tree, and unless told otherwise at configuration time, the TimeoutControl node looks in the local environment for it. To use this behavior, a Compute node must be added somewhere before the TimeoutControl node to add this information, as shown by this ESQL, which also shows how you can set the timeout Identifier to be dynamic, and avoid clashes:
CREATE COMPUTE MODULE Timeout_Set
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot = InputRoot;
SET OutputLocalEnvironment.TimeoutRequest.Action = 'SET';
SET OutputLocalEnvironment.TimeoutRequest.Identifier = OutputRoot.XMLNSC.Data.UniqueId;
SET OutputLocalEnvironment.TimeoutRequest.StartDate = 'TODAY';
SET OutputLocalEnvironment.TimeoutRequest.StartTime = 'NOW';
SET OutputLocalEnvironment.TimeoutRequest.Count = 10;
SET OutputLocalEnvironment.TimeoutRequest.Interval = 5;
RETURN TRUE;
END;
END MODULE;
This could be implemented using a Mapping Node.
Do not forget to set your Compute node to Pass Message and LocalEnvironment. You must then change your TimeoutControl node to have a blank Request Location, if it has been changed from the default value:
This ESQL shows how to set a one-off timeout for 60 seconds in the future by generating a relative time:
CREATE COMPUTE MODULE UT_CONTROL_TIMEOUT_10
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot = InputRoot;
DECLARE jump INTERVAL;
SET jump = INTERVAL '60' SECOND;
DECLARE start TIME;
SET start = CURRENT_TIME + jump;
SET OutputLocalEnvironment.TimeoutRequest.Action = 'SET';
SET OutputLocalEnvironment.TimeoutRequest.Identifier = 'control';
SET OutputLocalEnvironment.TimeoutRequest.StartDate = 'TODAY';
SET OutputLocalEnvironment.TimeoutRequest.StartTime = start;
RETURN TRUE;
END;
END MODULE;