Delaying Polling Requests for Concurrent JMS Triggers
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.