Running the Timeout Processing sample

The Timeout Processing sample has two parts that are run separately:

Automatic timeout processing

After the AutomaticTimeout message flow is deployed, you need to do nothing more to run it; as the name suggests, it runs automatically. Messages appear ten seconds apart on the TIMEOUT_SAMPLE_OUT_1 queue while the broker is running.

Controlled timeout processing

After the ControlledTimeout message flow is deployed, you need to drive it with the sample messages as described below:
  1. Open the test message enqueue file SetTenTimeout.enqueue.
  2. Click Write to queue. A request message is sent to the TIMEOUT_SAMPLE_IN_1 queue, and ten copies of the original message, ten seconds apart, appear on the TIMEOUT_SAMPLE_OUT_2 queue.

When the test has completed, repeat the procedure with the SetUnlimitedTimeout.enqueue file. This writes a message containing an unlimited (non-terminating) timeout request to the TIMEOUT_SAMPLE_IN_2 queue, and copies of the original message, ten seconds apart, appear on the TIMEOUT_SAMPLE_OUT_2 queue. The output messages contain a fragment (the first <Invoice> record) of the original input message.

The unlimited timeout request runs until it is told to terminate. You can stop it with a corresponding cancellation request:

  1. Open the test message enqueue file CancelUnlimitedTimeout.enqueue. This contains nothing except a cancellation request for the unlimited timeout request contained in the SetUnlimitedTimeout.enqueue file.
  2. Click Write to queue. Messages stop appearing on the TIMEOUT_SAMPLE_OUT_2 queue.

You can also stop the ten-times timeout request in the same manner, using the CancelTenTimeout.enqueue file.

You can run the limited and unlimited timeouts together, by driving both messages into the flow close together. The "Controlled" node will process them as they each ping, and the output messages are mixed on the TIMEOUT_SAMPLE_OUT_2 queue. You cannot run two instances of either timeout request together - the second will generate an error in the Timeout Control node as it will not overwrite the existing request. Note that this is not a limitation of the Timeout nodes generally, it is a limitation of this sample - the timeout requests in the enqueue files in the sample have hard-coded identifiers.

Verifying success

Success is determined by the arrival of messages on the TIMEOUT_SAMPLE_OUT_1 and TIMEOUT_SAMPLE_OUT_2 queues. The first contains the messages from the AutomaticTimeout message flow, which are ten seconds apart and that will keep appearing while the message flow is running. The second contains the messages from the ControlledTimeout message flow, which are in groups, each separated by ten second intervals, depending on the order and timing of the request invocation.

To view the messages on the TIMEOUT_SAMPLE_OUT_1 queue, follow this procedure:

  1. On the workbench toolbar, click the Get a message from a Queue icon: Dequeue action icon.
  2. On the drop-down menu, click Get Message to open the Dequeue Message window.
  3. Enter WBRK6_DEFAULT_QUEUE_MANAGER for the queue manager and TIMEOUT_SAMPLE_OUT_1 for the queue.
  4. Click Read From Queue to read a message from the queue. The messages are automatically generated, and will look this:
<TimeoutRequest>
<Action>SET</Action>
<Identifier>SampleAuto</Identifier>
<StartDate>2005-06-06</StartDate>
<StartTime>12:36:44.900</StartTime>
<Count>5</Count>
<Interval>10</Interval>
<IgnoreMissed>TRUE</IgnoreMissed>
<AllowOverwrite>TRUE</AllowOverwrite>
</TimeoutRequest>

The messages on the TIMEOUT_SAMPLE_OUT_2 queue are viewed in the same way, and contain either the entire input message or a small part of it.

Main Page icon   Back to sample home