Listener ports running in Application Server Facilities (ASF) mode
Listener ports running in ASF mode used by message-driven bean applications create conversations for each server session. One monitors a destination for suitable messages and another runs a message-driven bean instance to process messages. The number of conversations for each listener port can be calculated from a maximum number of sessions.
By default, listener ports will run in ASF mode as part of the 1.1 specification that defines the mechanism which application servers should use to detect messages and deliver them to message-driven beans for processing. Message-driven bean applications that are set up to use listener ports in this default mode of operation create conversations:
- One conversation for the listener port to monitor a destination for suitable messages
- Listener ports are configured to use a JMS connection factory. When a listener port starts, a request is made for a JMS connection from the connection factory free pool. The connection is returned to the free pool when the listener port is stopped. For more information about how the connection pool is used, and how this affects the number of conversations to IBM MQ , see JMS connection factories.
- One conversation for every server session used to run a message-driven bean instance to process messages
- The listener port property Maximum sessions specifies the maximum number of server sessions that can be active at any one time for a given listener port. This property has the default value of 10. Server sessions are created as they are needed, and make use of JMS sessions taken from the session pool associated with the JMS connection that the listener port is using.
If a server session has been idle for the period of time specified by the Message Listener Service custom property SERVER.SESSION.POOL.UNUSED.TIMEOUT, the session is closed and the JMS session used is returned to the session pool free pool. The JMS session will remain in the session pool free pool until it is needed, or it is closed because it has been idle in the free pool for longer than the value of the session pool's Unused timeout property.
For more information about how the session pool is used, and how the conversations between WebSphere Application Server and IBM MQ are managed, see JMS connection factories.
For more information about the Message Listener Service custom property SERVER.SESSION.POOL.UNUSED.TIMEOUT, see Monitor server session pools for listener ports in the WebSphere Application Server product documentation.
Calculating the maximum number of conversations from a single listener port to IBM MQ
We can calculate the maximum number of conversations from a single listener port to IBM MQ by using the following formula:Maximum number of conversations = Maximum sessions + 1The number of channel instances that will be created to allow this number of conversations to take place can be worked out using the following calculation:
Maximum number of channel instances = Maximum number of conversations / SHARECNV for the channel being usedAny remainder from this calculation can be rounded up. For a simple listener port that is using the default value for the Maximum sessions property, the maximum number of conversations that can exist between WebSphere Application Server and IBM MQ for this listener port is calculated as:
Maximum number of conversations = Maximum sessions + 1For example:
= 10 + 1 = 11If this listener port is connecting to IBM MQ using a channel that has the SHARECNV property set to 10, then the number of channel instances that will be created is calculated as:
Maximum number of channel instances = Maximum number of conversations / SHARECNV for the channel being usedFor example:
= 11 / 10 = 2 (rounded up to nearest connection)