Software AG Products 10.7 | Integrate Software AG Products Using Digital Event Services | Integration Server Administrator’s Guide | Managing JMS Triggers | Controlling Thread Usage for JMS Triggers | Establishing a Threshold for Using Multiple Threads with a Concurrent JMS Trigger
 
Establishing a Threshold for Using Multiple Threads with a Concurrent JMS Trigger
By default, concurrent JMS triggers begin using multiple server threads when there is more than one message to process. Integration Server increases the number of server threads used by the trigger until the JMS trigger uses the maximum number of threads that it can to retrieve and process messages. The maximum number of threads that a JMS trigger can use is determined by the Max execution threads property value set for the JMS trigger.
To limit the number of threads used by concurrent JMS triggers, you can establish a threshold that determines when the JMS trigger becomes multithreaded. A threshold can be beneficial when a concurrent JMS trigger requires additional processing resources at specific times during the day due to an influx of messages, but for the majority of the day the JMS trigger receives relatively few messages. When the rate if incoming messages is low, the JMS trigger may need only a single thread to process messages efficiently.
The threshold is based on the consecutive number of successful requests for more messages that the JMS trigger makes to the JMS provider. When a threshold is in use, a concurrent JMS trigger initially uses a single thread to retrieve and process messages. When the number of successful consecutive requests for more messages is equal to the specified threshold, the JMS trigger becomes multithreaded. The maximum number of threads Integration Server can use for the JMS trigger is equal to the value of the Max execution threads property plus one. (When a concurrent JMS trigger is multithreaded, Integration Server dedicates a server thread to managing the message consumer pool for the trigger.) The concurrent JMS trigger remains multithreaded until the message consumers created by the threads time out. The watt.server.jms.trigger.pooledConsumer.timeout property value determines when a message consumer times out. When a consumer times out, the JMS trigger releases the associated server thread. Eventually, when no messages are being received, the concurrent JMS trigger returns to using a single thread.
To use a threshold to determine when a JMS trigger transitions from being single threaded to multithreaded, set the watt.server.jms.trigger.concurrent.consecutiveMessageThreshold server property to a positive integer greater than 0 (zero). This property indicates the consecutive number of successful requests for more messages from the JMS provider that the concurrent JMS trigger must make before the trigger becomes multithreaded. For example, when this property is set to 1000, a concurrent JMS trigger becomes multithreaded it makes 1000 consecutive successful requests for more messages from the JMS provider. The default for this property is 0, which indicates that the use of a threshold for making a concurrent JMS trigger multithreaded is disabled. When use of a threshold is disabled, the concurrent JMS trigger will always be multithreaded when more than one message is available for processing.
Note:
The threshold for determining when a concurrent JMS trigger becomes multithreaded applies to all of the concurrent JMS triggers on the Integration Server. This includes standard JMS triggers, SOAP-JMS triggers, and WS-Endpoint triggers. It is not configurable on a per JMS trigger basis.