Integration Server Administrator's Guide : Managing JMS Triggers : Delaying Polling Requests for Concurrent JMS Triggers : How JMS Trigger Delays a Polling Request
How JMS Trigger Delays a Polling Request
 
Examples of Extended Polling Delay Configuration
The following table explains how a concurrent JMS trigger polls for messages when Integration Server is configured to delay polling requests for inactive concurrent JMS triggers.
Stage
Description
1
The concurrent JMS trigger becomes inactive.
Integration Server considers a concurrent JMS trigger to be inactive if none of the message consumers associated with the JMS trigger received messages in the last round of requests to the JMS provider.
2
If the watt.server.jms.trigger.extendedDelay.delayIncrementInterval parameter is greater than or equal to 1, the polling delay feature is enabled. The JMS trigger begins to delay polling requests by the amount of time specified by the first integer in the watt.server.jms.trigger.extendedDelay.delays parameter.
For example, suppose that watt.server.jms.trigger.extendedDelay.delays = 1000, 2000, 3000. When the JMS trigger becomes inactive, the JMS trigger
1. Waits 1000 milliseconds
2. Polls the JMS provider for more messages
When the watt.server.jms.trigger.extendedDelay.delayIncrementInterval parameter is set to 0, the polling delay feature is disabled. Integration Server will not introduce a delay between polling requests.
3
After the interval specified by watt.server.jms.trigger.extendedDelay.delayIncrementInterval elapses, the JMS trigger begins to delay polling requests by the amount of time specified by the second integer in watt.server.jms.trigger.extendedDelay.delays.
For example, suppose that watt.server.jms.trigger.extendedDelay.delayIncrementInterval, which is measured in milliseconds, is set to 5000. The JMS trigger polls for new messages at the frequency described in Stage 2 for 5000 milliseconds. After 5000 milliseconds elapse, the JMS trigger begins using the second extended delay value. If watt.server.jms.trigger.extendedDelay.delays = 1000, 2000, 3000, the JMS trigger now waits 2000 millisecond before polling the JMS provider for more messages.
4
After the interval specified by watt.server.jms.trigger.extendedDelay.delayIncrementInterval elapses, the JMS trigger begins to delay polling request by the amount of time specified by the third integer in watt.server.jms.trigger.extendedDelay.delays.
For example, suppose that watt.server.jms.trigger.extendedDelay.delayIncrementInterval, which is measured in milliseconds, is set to 5000. The JMS trigger polls for new messages at the frequency described in Stage 3 for 5000 milliseconds. After 5000 milliseconds elapse, the JMS trigger begins using the third extended delay value. If watt.server.jms.trigger.extendedDelay.delays = 1000, 2000, 3000, the JMS trigger now waits 3000 milliseconds before polling the JMS provider for more messages.
5
Each time the interval specified by watt.server.jms.trigger.extendedDelay.delayIncrementInterval elapses, the JMS trigger uses the next value in watt.server.jms.trigger.extendedDelay.delays to change the length of time between polling requests. When the JMS trigger reaches the last value in watt.server.jms.trigger.extendedDelay.delays, the JMS trigger uses the specified polling delay until the JMS trigger retrieves a message from the JMS provider.
6
When a polling request to the JMS provide returns one or more messages, Integration Server considers the JMS trigger to be active and stops using a polling delay.
Copyright © 2015- 2017 Software AG, Darmstadt, Germany. (Innovation Release)

Product LogoContact Support   |   Community   |   Feedback