Configuring Producer Caching for Sending JMS Messages
When sending a JMS message, Integration Server creates and closes a new JMS Session object and a JMS MessageProducer object for each message. This can introduce overhead for some JMS providers. To improve performance when sending JMS messages, you can configure producer-side pooling. For each JMS connection alias, Integration Server can create the following:
A default session pool containing JMS Session objects. When a default session pool is defined for a JMS connection alias,
Integration Server draws from a pool of open JMS Sessions for sending a JMS message instead of opening and closing a JMS Session for each JMS message.
Integration Server uses the default session pool only when sending a message to a destination that does not have its own pool. When using the default session pool,
Integration Server creates a new MessageProducer each time it sends a JMS message.
Destination-specific pools for sending JMS messages to specific destinations.
Integration Server creates a pool for each specified destination. The composition of a destination-specific pool varies depending on the transaction type of the JMS connection alias.
For a non-transacted JMS connection alias, an entry in a destination-specific pool consists of a Session object and a MessageProducer object. When sending a JMS message to one of the specified destinations,
Integration Server uses a Session object and MessageProducer object from the pool instead of creating and closing a Session object and MessageProducer object for each JMS message.
For a transacted JMS connection alias, an entry in a destination-specific pool contains a Session object. When sending a JMS message to one of the specified destinations,
Integration Server uses a Session object from the pool instead of creating and closing a Session object for each JMS message.
Integration Server creates a new MessageProducer each time it sends a JMS message.
Note: | Integration Server supports session caching for transacted JMS connection aliases when the JMS provider is Universal Messaging 10.1 or WebSphere MQ 7.5. |
You can specify the minimum and maximum sizes for the default session pool and all destination pools. Additionally, you can identify the destinations for which Integration Server creates specific pools. If the JMS connection alias specifies the use of a connection factory object to connect to the JMS provider, you specify a single list of destinations. If the JMS connection alias specifies the Native webMethods API for connecting to the webMethods Broker, you must specify separate lists for the queues and topics for which you want Integration Server to create destination pools.
Consider the following examples that explain how Integration Server creates session and destination pools based on the information specified for transacted and non-transacted connection aliases:
Example of creating session and destination pools for a non-transacted JMS connection alias
Suppose that a non-transacted JMS connection alias named "myAlias" connects to the webMethods Broker using the Native webMethods API and the fields are set as follows:
Field | Value |
Minimum Pool Size | 1 |
Maximum Pool Size | 10 |
Minimum Pool Size per Destination | 1 |
Maximum Pool Size per Destination | 5 |
Queue List | myQueue1; myQueue2 |
Topic List | myTopic |
Idle Timeout | 70000 |
Using the above information, Integration Server creates a default session pool with a minimum size of 1 and a maximum size of 10. This pool contains JMS Session objects only. Integration Server uses an entry from the pool when sending a message to destination that does not have its own pool.
Integration Server also creates three destination pools: one each for the queues myQueue1 and myQueue2, and one for the topic myTopic. Each of these pools has a maximum size of 5 pool entries. Messages sent to the destinations myQueue1, myQueue2, or myTopic will use an entry (a Session object and MessageProducer object) from the pool created for the destination. Messages sent to other destinations will use a Session from the default session pool.
An entry in the default or destination-specific pools expires after the entry has been inactive for over 70000 milliseconds (70 seconds).
Example of creating session and destination pools for a transacted JMS connection alias
Suppose that a transacted JMS connection alias named "myAlias1" connects to WebSphere MQ 7.5 using JNDI and the fields are set as follows:
Field | Value |
Minimum Pool Size | 1 |
Maximum Pool Size | 15 |
Minimum Pool Size per Destination | 1 |
Maximum Pool Size per Destination | 10 |
Destination Lookup Name List | myQueue1; myQueue2; myTopic1 |
Idle Timeout | 80000 |
Using the above information, Integration Server creates a default session pool with a minimum size of 1 and a maximum size of 15. This pool contains JMS Session objects only. Integration Server uses an entry from the pool when sending a message to destination that does not have its own pool.
Integration Server also creates three destination pools: one each for the queues myQueue1 and myQueue2, and one for the topic myTopic1. Each of these pools has a maximum size of 10 pool entries. Messages sent to the destinations myQueue1, myQueue2, or myTopic1 will use an entry (a Session object) from the pool created for the destination. Messages sent to other destinations will use a Session from the default session pool.
An entry in the default or destination-specific pools expires after the entry has been inactive for over 80000 milliseconds (80 seconds).
