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. In the Message Brokers Toolkit, switch to the Broker Application Development perspective.
  2. In the Broker Development view, expand the Timeout Message Flows project.
  3. Double click SetTenTimeout.mbtest to open the file in the Test Client.
  4. In the Test Client click Enqueue.
  5. Click Send Message. 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.mbtest 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. Double click CancelUnlimitedTimeout.mbtest to open the file in the Test Client. The file contains nothing except a cancellation request for the unlimited timeout request contained in the SetUnlimitedTimeout.mbtest file.
  2. Click Send Message. 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.mbtest 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 .mbtest 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 WBRK61_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 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.

Back to sample home