Software AG Products 10.7 | Administering Integration Server | Managing JMS Triggers | Controlling Thread Usage for JMS Triggers | Throttling Thread Usage for JMS Triggers
 
Throttling Thread Usage for JMS Triggers
Integration Server provides controls that you can use to throttle the server thread usage by JMS triggers. You can use the controls to:
*Set the percentage of the server thread pool that Integration Server can use for receiving and processing all JMS triggers.
*Reduce maximum execution threads by the same percentage across all concurrent JMS triggers. This also decreases the rate at which concurrent JMS triggers process messages.
*To throttle thread usage for JMS triggers
1. Open the Integration Server Administrator if it is not already open.
2. Go to Settings > Messaging.
3. Click JMS Trigger Management.
4. Click Edit JMS Global Trigger Controls.
5. In the Thread Pool Throttle field, type the maximum percentage of the server thread pool that can be used for JMS triggers. This includes threads used to retrieve messages from the JMS provider and threads used to process messages. You must enter a value greater than zero.
6. In the Individual Trigger Processing Throttle field, select the value, as a percentage of the configured maximum execution threads value, at which you want to the server to function. Integration Server applies this percentage to the maximum execution threads value for all concurrent JMS triggers.
This value applies to concurrent JMS triggers only.
7. Click Save Changes.
Notes:
*If the Thread Pool Throttle percentage does not evaluate to a whole number when applied to the size of the server thread pool, Integration Server rounds up or down to the nearest whole number.
*Serial JMS triggers always process one message at a time. For a serial trigger, Integration Server uses the same thread for receiving and processing a message. The Individual Trigger Processing Throttle does not affect serial JMS triggers.
*Concurrent JMS triggers use a pool of consumers to receive and process messages. Each consumer will use a thread from the server thread pool to receive and process a message. A concurrent JMS trigger dedicates an additional thread per connection to managing the pool of consumers. For example, a concurrent JMS trigger configured to use one connection to the JMS provider and configured to process up to 10 messages at a time can use a maximum of 11 server threads. As another example, a concurrent JMS trigger configured to use 2 connections to the JMS provider and configured to process up to 10 messages at a time can use a maximum of 12 threads. For more information about using multiple connections for a concurrent JMS trigger, see Allowing Multiple Connections for a JMS Connection Alias.
*For a concurrent JMS trigger configured to use multiple connections to the webMethods Broker, the trigger's maximum execution threads will never be less than the number of connections specified in the trigger's Connection count property. This is true even when reducing the Individual Trigger Processing Throttle.
*If the percentage by which you reduce concurrent JMS trigger execution threads does not resolve to a whole number for a JMS trigger, Integration Server rounds up or rounds down to the nearest whole number. However, if rounding down would set the value to 0, the Integration Server rounds up to 1. For example, if you reduce Individual Trigger Processing Throttle to 10% of maximum, a concurrent JMS trigger with a maximum execution threads value of 12 would have an adjusted value of 1 (Integration Server rounds 1.2 down to 1). A concurrent JMS trigger with a maximum execution threads value of 4 would have an adjusted value of 1 (Integration Server rounds 0.4 up to 1).
*When you reduce the Individual Trigger Processing Throttle and save your changes, Integration Server does not meet the adjusted maximum by terminating any threads currently executing concurrent JMS triggers. Integration Server allows server threads processing messages for concurrent JMS triggers to execute to completion. Integration Server waits until the number of threads executing for a concurrent JMS trigger is less than the adjusted maximum before dispatching another server thread for that JMS trigger.