About Message Processing

Message processing determines how Integration Server processes the messages received by the JMS trigger. You can specify serial processing or concurrent processing.

  • In serial processing, Integration Server processes messages received by a JMS trigger one after the other in the order in which the messages were received from the JMS provider.
  • In concurrent processing, Integration Server processes messages received from the JMS provider in parallel.

Serial Processing

In serial processing, Integration Server processes messages received by a JMS trigger one after the other in the order in which the messages were received from the JMS provider. Integration Server uses a single thread for receiving and processing a message for a serial JMS trigger. Integration Server evaluates the first message it receives, determines which routing rule the message satisfies, and executes the service specified in the routing rule. Integration Server waits for the service to finish executing before processing the next message received from the JMS provider.

If you want to process messages in the same order in which JMS clients sent the messages to the JMS provider, you will need to configure the JMS provider to ensure that messages are received by the JMS trigger in the same order in which the messages are published.

For information about using serial JMS triggers in a cluster to process messages from a single destination in publishing order, see the Using webMethods Integration Server to Build a Client for JMS .

Tip: If your trigger contains multiple routing rules to handle a group of messages that must be processed in a specific order, use serial processing.

Concurrent Processing

In concurrent processing, Integration Server processes messages received from the JMS provider in parallel. That is, Integration Server processes as many messages for the JMS triggers as it can at the same time, using a separate server thread to process each message. Integration Server does not wait for the service specified in the routing rule to finish executing before it begins processing the next message. You can specify the maximum number of messages Integration Server can process concurrently. This equates to specifying the maximum number of server threads that can process messages for the JMS trigger at one time.

Concurrent processing provides faster performance than serial processing. Integration Server processes the received messages more quickly because it can process more than one message for the trigger at a time. However, the more messages Integration Server processes concurrently, the more server threads it dispatches, and the more memory the message processing consumes.

Additionally, for JMS triggers with concurrent processing, Integration Server does not guarantee that messages are processed in the order in which they are received.

A concurrent trigger can connect to the JMS provider through multiple connections, which can increase trigger throughout. For more information about multiple connections, refer to Using Multiple Connections to Retrieve Messages for a Concurrent JMS Trigger.

Message Processing and Message Consumers

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.

Message Processing and Load Balancing

Load balancing allows multiple consumers on one or more Integration Servers to retrieve and process messages concurrently. Load balancing is necessary for concurrent JMS triggers regardless of whether or not they are running in a cluster of Integration Servers. This is because concurrent JMS triggers use multiple consumers. Each consumer receives a message from the JMS provider, processes the message, and acknowledges the message to the JMS provider. Each consumer needs to consume a message from the same destination, but not process any duplicate message. For information about configuring load-balancing, see webMethods Integration Server Administrator’s Guide .

About Batch Processing for Standard JMS Triggers

You can configure a standard JMS trigger and its associated trigger service to process a group or “batch” of messages at one time. Batch processing can be an effective way of handling a high volume of small messages for the purposes of persisting them or delivering them to another back-end resource. For example, you might want to take a batch of messages, create a packet of SAP IDocs, and send the packet to SAP with a single call. Alternatively, you might want to insert multiple messages into a database at one time using only one insert. The trigger service processes the messages as a unit as opposed to in a series.

The Max batch messages property indicates the maximum number of messages that the trigger service can receive at one time. For example, if the Max batch messages property is set to 5, Integration Server passes the trigger service up to 5 messages received by the JMS trigger to process during a single execution.

Integration Server uses one consumer to receive and process a batch of messages. During pre-processing, Integration Server checks the maximum delivery count for each message and, if exactly-once processing is configured, determines whether or not the message is a duplicate. Integration Server then bundles the message into a single IData and passes it to the trigger service. If the message has exceeded the maximum delivery count or is a duplicate message, Integration Server does not include it in the message batch sent to the trigger service.

Note: The watt.server.jms.trigger.maxDeliveryCount property determines the maximum number of times the JMS provider can deliver a message to a JMS trigger.

Integration Server acknowledges all the messages received in a batch from the JMS provider at one time. This includes messages that failed pre-processing. As described by the Java Message Service standard, when a client acknowledges one message, the client acknowledges all of the messages received by the session. Because Integration Server uses a consumer that includes a javax.jms.MessageConsumer and a javax.jms.Session, when Integration Server acknowledges one message in the batch, it effectively acknowledges all the messages received in the batch.

If a batch of messages is not acknowledged or they are recovered back to the JMS provider, the JMS provider can redeliver all of the messages in the batch to the JMS trigger. However, when using webMethods Broker, Integration Server can acknowledge individual messages that fail pre-processing.

Guidelines for Configuring Batch Processing

When configuring JMS trigger for batch processing, keep the following in mind:

  • The trigger service must be coded to handle multiple messages as input. That is, the trigger service must use the pub.jms.batchTriggerSpec as the service signature.
  • When receiving a batch of messages, Integration Server evaluates the local filter in the routing rule against the first message in the batch only.
  • A transacted JMS trigger can be used for batch processing if the JMS connection alias used by the trigger connects to a JMS provider that supports reuse of transacted JMS sessions. If the JMS provider does not support reuse of transacted JMS sessions, set Max batch processing to 1.

    Consult the documentation for your JMS provider to determine whether or not the JMS provider supports the reuse of transacted JMS sessions. Note that webMethods Broker version 8.2 and higher, Software AG Universal Messaging version 9.5 SP1 and higher, and webMethods Nirvana version 7 and higher support the reuse of transacted JMS sessions.

  • A JMS trigger that contains an All (AND) or Only one (XOR) join cannot use batch processing.
  • SOAP-JMS triggers cannot process messages in batches.

Using Multiple Connections to Retrieve Messages for a Concurrent JMS Trigger

You can configure a concurrent JMS trigger to obtain multiple connections to the JMS provider. Multiple connections can improve trigger throughput. Keep in mind, however, that each connection used by the JMS trigger requires a dedicated Integration Server thread, regardless of the current throughput.

For a JMS trigger to have multiple connections to the JMS provider, the JMS connection alias used by the trigger must be configured to create a new connection for each trigger. For more information about JMS connection aliases, refer to webMethods Integration Server Administrator’s Guide .

A concurrent JMS trigger can use multiple connections to retrieve messages from a JMS provider. For a trigger to use multiple connections, the following must be true:

  • The JMS trigger must be configured for concurrent processing. Serial JMS triggers cannot use multiple connections.
  • The JMS trigger must receive messages from a queue or from a topic with a durable subscriber. JMS triggers that receive messages from non-durable subscribers (topics) cannot use multiple connections.
  • The JMS trigger must not have the Ignore locally published option selected when the JMS connection alias is configured to use the Create New Connection per Trigger option. For the JMS trigger to ignore locally published messages, the publisher and subscriber must share the same connection. When the JMS connection alias uses multiple connections per trigger, the publisher and subscriber will not share the same connection.
  • The JMS connection alias used by the JMS trigger must be configured to create an individual connection for each trigger. To configure a JMS alias to create individual connections for each JMS trigger, select the Create New Connection per Trigger option on the Messaging > JMS settings > Create JMS connection alias page on Integration Server Administrator.
Note: When using multiple connections to the webMethods Broker, Integration Server uses a different client ID for each JMS trigger that uses the JMS connection alias. However, when Integration Server connects to other JMS providers, it uses the same client ID for each connection. Some JMS providers do not permit multiple connections to use the same client ID to retrieve messages from a Topic with a durable subscriber. Review the JMS provider documentation before configuring the use of multiple connections for a JMS connection alias and any concurrent JMS triggers that use the JMS connection alias.

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. A prefetch cache is also referred to as a consumer 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 for the trigger from either Universal Messaging or webMethods Broker. When a 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 JMS provider (Universal Messaging or 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. It can also reduce the burden on Universal Messaging or webMethods Broker as it reduces the number or requests to which the JMS provider needs to respond.

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, reducing the number of prefetched messages may actually decrease the time needed to retrieve and process a message.

Note: This prefetch cache can be used with JMS triggers that receive messages from Universal Messaging or webMethods Broker only. webMethods Broker is deprecated.

Which JMS triggers can use a prefetch cache depends and how that works depends on whether JMS provider is Universal Messaging or Broker.

Prefetching Messages from IBM 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.

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.

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 frequency with which a concurrent JMS trigger that uses prefetch caching polls the Universal Messaging for more messages is controlled by the watt.server.jms.trigger.caching.pollingInterval parameter.

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.

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

Configuring Message Processing

About this task

Keep the following points in mind when configuring message processing for a JMS trigger:
  • You can configure a standard JMS trigger and its associated trigger service to process a group or “batch” of messages at one time. For information about batch processing, see About Batch Processing for Standard JMS Triggers and Guidelines for Configuring Batch Processing.
  • If the JMS provider from which the JMS trigger retrieves messages does not support concurrent access by durable subscribers, you must set the Max execution threads property to 1 for the concurrent JMS trigger. Consult the documentation for your JMS provider for more information.
  • Non-durable subscribers, i.e., JMS triggers that subscribe to topics but do not specify a durable subscriber, cannot receive messages in a load-balanced fashion. Because it is possible for a JMS trigger using a non-durable subscriber to process duplicates of a message, set Max execution threads to 1.
  • For a destination that acts as a shared state client, the serial processing mode corresponds to a shared state order mode of publisher; a concurrent processing mode corresponds to a shared state order mode of none.
  • If you use webMethods Broker as the JMS provider, changing the message processing mode for a JMS trigger can create a mismatch with the corresponding destination on the webMethods Broker. If you do not use Designer to make the changes, you need to use the webMethods Broker interface of My webMethods to update the destination.
  • A concurrent JMS trigger can use multiple connections to retrieve messages from the JMS provider. For information about requirements for using multiple connections, see Using Multiple Connections to Retrieve Messages for a Concurrent JMS Trigger.
  • You can only use the Max prefetch size property when the JMS provider is webMethods Broker or Universal Messaging. For more details about requirements for using this feature, see Prefetching Messages from webMethods Broker and Prefetching Messages with Universal Messaging.
  • When setting the Max execution threads for concurrent JMS triggers keep in mind the size and number of the messages received by the trigger for parallel processing and the resources needed for trigger service execution. Consider starting with a baseline formula of:

    Max execution threads = Number of cores multiplied by 2 for CPU bound services

    For example, if a concurrent trigger resides on an Integration Server with 4 core CPU, start with Max execution threads= 8. If the trigger service is long-running, processes large messages, consumes a high amount of resources (CPU bound), or the system on which Integration Server runs is configured in a resource-constrained manner, set Max execution threads to a lower value. If the trigger service executes quickly or processes small messages or are mostly I/O bound, set Max execution threads to a higher value.

To configure message processing for a JMS trigger

Procedure

  1. In the Package Navigator view of Designer, open the JMS trigger for which you want to specify message processing.
  2. In the Properties view, under Messaging processing, next to Processing mode, select one of the following:
    Select... To...
    Serial Specify that Integration Server should process messages received by the trigger one after the other.
    Concurrent Specify that Integration Server should process multiple messages for this trigger at one time.

    In the Max execution threads property, specify the maximum number of messages that Integration Server can process concurrently.

  3. If you want this trigger to perform batch processing, next to Max batch messages, specify the maximum number of messages that the trigger service can receive at one time. If you do not want the trigger to perform batch processing, leave this property set to 1. The default is 1.
  4. If you want this trigger to use multiple connections to receive messages from the JMS provider, next to Connection count, specify the number of connections you want the JMS trigger to make to the JMS provider. The default is 1.
  5. If you want Integration Server to use the prefetch cache with this JMS trigger, in the Properties view, under Universal Messaging and webMethods Broker do one of the following for Max prefetch size:
    • Specify the number of messages you want Integration Server to retrieve and cache for this JMS trigger. The default is 10 messages.
    • Specify -1 if the JMS trigger retrieves messages from webMethods Broker and you want the value of watt.server.jms.trigger.maxPrefetchSize parameter to determine how many messages Integration Server retrieves and caches for the JMS trigger.
    • Specify 0 if you do not want to use the prefetch cache with this JMS trigger.
  6. Click File > Save.

    If the destination is Queue or Topic (Durable Subscriber) and the JMS trigger is connected to the queue or durable subscriber, Designer prompts you to update the corresponding destination on the webMethods Broker with the changed shared state order mode, click Yes to update the destination. Click No to skip the destination update. Note that messages might be lost while Designer and Integration Server make the update because Integration Server deletes and recreates the subscription as part of the update.

    Note: A JMS trigger is connected to the webMethods Broker when the specified JMS connection alias is enabled and connected to the webMethods Broker.