Integration Server 10.11 | Integration Server Administrator's Guide | Managing JMS Triggers | Delaying Polling Requests for Concurrent JMS Triggers
 
Delaying Polling Requests for Concurrent JMS Triggers
 
How JMS Trigger Delays a Polling Request
You can reduce the resources that a concurrent JMS trigger uses for message polling by delaying polling requests when the JMS trigger is inactive. If the polling delay feature is enabled, an inactive concurrent JMS trigger waits the specified length of the polling delay before polling the JMS provider for more messages. You can configure Integration Server to gradually increase the delay between poling requests while the JMS trigger remains inactive.
Note:
A concurrent JMS trigger is considered 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.
During a polling delay, the JMS trigger will not receive any messages. However, the JMS trigger does not use resources from the JMS provider during the delay. If requests for more messages are expensive for your chosen JMS provider, you might want to use a polling delay to decrease the demands made by an inactive concurrent JMS trigger on the JMS provider.
Configuring Integration Server to delay polling requests has minimal impact on the time required to shut down Integration Server. As part of shut down, Integration Server shuts down each JMS trigger. Integration Server can interrupt the extended delay to begin shutting down the JMS trigger.
To use a polling delay, you need to specify the following:
*The length of the delay that should elapse before the polling interval begins. The watt.server.jms.trigger.extendedDelay.delays parameter determines the length of the delay. If you want to use a gradually increasing delay, you indicate the incremental delays by specifying a comma-separated list of integers. The watt.server.jms.trigger.extendedDelay.delays parameter is measured in milliseconds and has a default value of: 0, 1000, 2000, 3000
*The time interval at which Integration Server introduces the polling delay for an inactive concurrent JMS trigger. If the JMS trigger remains inactive, the same time interval determines when Integration Server increases the delay between polling requests. The time interval is determined by the watt.server.jms.trigger.extendedDelay.delayIncrementInterval parameter. This parameter is measured in millisecond and has a default value or 0 which indicates that Integration Server does not introduce a delay between polling requests for inactive concurrent JMS triggers.
Note:
Concurrent JMS triggers that receive messages from Universal Messaging and use the prefetch caching functionality, do not use the delayed message polling behavior described here.