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 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.