Designer 10.5 | webMethods Service Development Help | Working with JMS Triggers | About Message Processing | Retrieving Multiple Messages for a JMS Trigger with Each Request
 
Retrieving Multiple Messages for a JMS Trigger with Each Request
You can instruct Integration Server to retrieve multiple messages for a JMS trigger with each request by using the prefetch cache. When a JMS trigger is configured to use the prefetch cache, Integration Server retrieves multiple messages for the trigger each time Integration Server requests more messages from the webMethods Broker. When the JMS trigger needs a new message to process, the JMS trigger retrieves the message from the local, prefetched cache instead of requesting a new message from the webMethods Broker. Use of the prefetch cache may improve performance of the JMS trigger because it reduces the time spent retrieving messages for the JMS trigger.
Using the prefetch cache is most likely to improve performance for JMS triggers that process many small messages and have trigger services that execute quickly. If the JMS trigger receives large messages or the JMS trigger has long-running trigger services, using the prefetch cache may increase the overall time needed to retrieve and process a message. For JMS triggers that fit this use case, including concurrent JMS triggers, reducing the number of prefetched messages may actually decrease the time needed to retrieve and process a message. You may need to set the number of prefetched messages to 1 (one).
Note:
This prefetch cache can be used with JMS triggers that receive messages from webMethods Broker only. webMethods Broker is deprecated.
The use of the prefetch cache for a JMS trigger and the number of messages Integration Server might retrieve with each request are determined by 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.