Integration Server 10.7 | JMS Client Development Guide | Working with JMS Triggers | About Message Processing | Retrieving Multiple Messages for a JMS Trigger with Each Request | Prefetching Messages from webMethods Broker
 
Prefetching Messages from webMethods Broker
When Broker is the JMS provider, either serial or concurrent JMS triggers can prefetch messages. The number of messages Integration Server might retrieve with each request is determined by the value of the Max prefetch size property for the JMS trigger and the value of the watt.server.jms.trigger.maxPrefetchSize parameter.
*When the Max prefetch size property is greater than 0, Integration Server uses the prefetch cache with the JMS trigger. The Max prefetch size property value specifies the number of messages that Integration Server might retrieve and cache for the trigger. The default is 10.
*When the Max prefetch size property is set to -1, Integration Server uses the prefetch cache with the JMS trigger. The watt.server.jms.trigger.maxPrefetchSize parameter value determines how many messages Integration Server might retrieves and cache for the JMS trigger.
*When the Max prefetch size property is set to 0, Integration Server does not use the prefetch cache with the JMS trigger.
When the prefetch cache is in use and the number of messages retrieved by Integration Server is greater than one, the same server thread might process all of the messages retrieved by the prefetch request. This is true even for concurrent JMS triggers. The first thread for the concurrent JMS trigger processes the first set of prefetched messages. The second thread for the concurrent JMS trigger processes the second set of prefetched messages.
For example, suppose that the number of available messages is 22, Max execution threads is 4, and Max prefetch size is 10. In the initial request for messages, the first server thread may retrieve 10 messages. The same server thread will process these first 10 messages. The second server thread may retrieve 10 messages, all of which will be processed by the second server thread. The third server thread may retrieve the remaining 2 messages, both of which will be processed by the third server thread. While the concurrent JMS trigger can use up to 4 server threads, Integration Server might use only 3 server threads to retrieve and process messages due to the way in which a JMS trigger processes prefetched messages. A concurrent JMS trigger will use all of the configured execution threads to process messages only when the number of messages on the webMethods Broker is greater than the number of messages that can be prefetched.
Note:
When you are working with a cluster of Integration Servers, the prefetch behavior might appear at first to be misleading. For example, suppose that you have a cluster of two Integration Servers. Each Integration Server contains the same JMS trigger. Twenty messages are sent to a destination from which JMS trigger receives messages. It might be expected the JMS trigger on Integration Server 1 will receive the first message, the JMS trigger on Integration Server 2 will receive the second message, and so forth. However, what may happen is that the JMS trigger on Integration Server 1 will receive the first 10 messages and the JMS trigger on Integration Server 2 will receive the second 10 messages.