The Timeout Processing sample has two parts that are run separately:
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.
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:
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.
To view the messages on the TIMEOUT_SAMPLE_OUT_1 queue, follow this procedure:
<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.