Integration Server uses a consumer to receive messages for a JMS trigger. This consumer encapsulates the actual javax.jms.MessageConsumer and javax.jms.Session. The type of message processing affects how Integration Server uses consumers to receive messages.

Serial JMS triggers have one consumer and will use one thread from the server thread pool to receive and process a message.

Concurrent JMS triggers use a pool of consumers to receive and process messages. Each consumer uses one thread from the server thread pool to receive and process a message. For a concurrent JMS trigger, the Max execution threads property specifies how many threads can be used to process messages for the trigger at one time. For concurrent JMS triggers, Integration Server also dedicates a thread to managing the pool of consumers. Consequently, the maximum number of threads that can be used by a JMS trigger is equal to the Max execution threads value plus 1. For example, a concurrent JMS trigger configured to use 10 threads at a time can use a maximum of 11 server threads.

When there are multiple connections to the webMethods Broker, the threads are divided among the connections. Therefore, if a trigger is configured so that Connection count is 2 and Max execution threads is set to 10, each connection will have 5 threads plus 1, for a total of 12 threads.

When a service is invoked through the JMS trigger, Integration Server does not consider the Max concurrent requests value set in the service properties and therefore execution of a service as a trigger service does not count towards the concurrent request limit. The maximum number of concurrent executions for services invoked by the JMS trigger is determined by the Max execution threads value set for the trigger.