Integration Server 11.1 | JMS Client Development Guide | Working with JMS Triggers | About Message Processing | Retrieving Multiple Messages for a JMS Trigger with Each Request | Prefetching Messages with Universal Messaging
 
Prefetching Messages with Universal Messaging
When Universal Messaging is the JMS provider from which a JMS trigger receives messages, the JMS trigger can use prefetch cache (consumer cache) when the trigger meets the following criteria:
*The JMS trigger uses concurrent processing. Serial JMS triggers that receive messages from Universal Messaging cannot user prefetch caching.
*The JMS trigger is not transacted. That is, the JMS connection alias that the trigger uses to retrieve messages has NO_TRANSACTION as the transaction type.
*If the JMS trigger receives messages from multiple destinations (that is, the trigger uses a join) and the number of destinations equals the Connection count property value. For example, if the JMS trigger receives messages from 3 destinations, and the Connection count value is 3, the JMS trigger can use the prefetch caching functionality. If the JMS trigger receives messages from 4 desalinations and Connection count value is 3, the JMS trigger cannot use the prefetch caching functionality.
*The Max prefetch size is greater than 1.
*The Max batch messages property of the JMS trigger is less than two.
When prefetch caching is used for JMS trigger, each request for messages retrieves up to the number of messages specified in the Max prefetch size property. The JMS trigger processes the first of the retrieved messages and places the remainder in a cache. Subsequent requests for messages by the trigger will pull messages from the cache instead of retrieving messages from Universal Messaging.
The watt.server.jms.trigger.caching.enablePrefetchCache server configuration parameter controls whether prefetch caching is enabled for concurrent JMS triggers connected to Universal Messaging. By default, the parameter value is true and prefetch settings are honored. When the value is false, prefetch caching is disabled, and any prefetch settings are ignored.
Note:
If a trigger is configured to prefetch messages, a retry failure occurs during processing of one of the messages, and the trigger is configured to suspend and retry later upon retry failure, the trigger does not process any messages that were already fetched but not acknowledged. When the trigger resumes, the trigger retrieves the number of messages specified in the prefetch size, starting with the message for which processing resulted in retry failure.
The frequency with which a concurrent JMS trigger that uses prefetch caching polls theUniversal Messaging for more messages is controlled by the watt.server.jms.trigger.caching.pollingInterval parameter.
When a concurrent JMS trigger uses prefetch caching, the following server configuration parameters do not apply and do not affect the frequency with which Integration Server polls Universal Messaging for more messages on behalf of the trigger:
*watt.server.jms.trigger.concurrent.consecutiveMessageThreshold
*watt.server.jms.trigger.concurrent.primaryThread.pollingInterval
*watt.server.jms.trigger.concurrent.secondaryThread.pollingInterval
*watt.server.jms.trigger.extendedDelay.delayIncrementInterval
*watt.server.jms.trigger.extendedDelay.delays
*watt.server.jms.trigger.maxPrefetchSize