Level: Introductory Sanjay M Kesavan (sanjay_mk@in.ibm.com), WebSphere MQ Java/JMS Level 3 Support, IBM
08 Feb 2006 Gain some basic insight into the considerations that should be taken when configuring listener ports in IBM® WebSphere® Application Server for maximum performance and throughput.
Introduction
When using message-driven beans with IBM WebSphere Application Server (V5 and V6), it is important to understand how to control the number of messages that are processed in parallel, and how this affects both the throughput of messages and the performance of the application server.
In this article, we refer to a message-driven bean (MDB) running in the point-to-point domain. The relations would be the same for a publish/subscribe domain and for a mixed domain (which is a new feature in the JMS 1.1 Specification).
Pools, ports, and properties
Connection pool
A JMS application creates queue connections from queue connection factories to communicate with JMS providers. These connections are pooled by WebSphere Application Server to improve the performance of JMS applications. Connection pooling removes the performance overhead when connections (and subsequently disconnections) to the messaging middleware are made.
When QueueConnectionFactory.createQueueConnection() is called by an application, the application server checks if any free connections to the queue manager used by the factory are available in the pool. If it finds a free connection, it will be marked in use and returned to the application. If all the connections in the pool are in use, or the createQueueConnection() method is being called on a connection factory for the first time, then a new connection is created and returned to the application. The reference of this new connection will be maintained by the pool, and be marked as being in use.
If the total number of connections in the pool have reached the maximum, then the QueueConnectionFactory.createQueueConnection() method will wait for an in-use connection to become available. The maximum time the method will wait for a connection in this situation is specified by the connection pool's connection timeout property.
Session pool
A queue session is created from a queue connection using the QueueConnection.createQueueSession() method. These sessions are also maintained in a pool (session pool) to improve performance.
Every queue connection has a session pool associated with it. This means that if we have a maximum of two connections in the connection pool, and a maximum of four sessions in the session pool, then we can have up to eight sessions available for that queue connection factory; this also means that we can only have four sessions per connection for this queue connection factory.
Listener port
The listener port acts as a JMS application that delivers messages to the onMessage() method of a MDB. You can think of a listener port as an application that uses the MDB (the object which implements javax.jms.MessageListener) for asynchronous message delivery.
If the initial state property of the listener port is started, the application server starts this listener port when the application server starts up. If a MDB has been configured to use the listener port, it will start processing any messages on the queue immediately. How quickly the messages are processed depends in part on the value of the listener port's maximum sessions property.
Maximum sessions property in the listener port
The maximum sessions property directly relates to the number of MDB instances that run in parallel for a listener port.
Thread pool in the message listener service
The message listener service is an internal thread that monitors listener ports; it controls the number of threads that will be used by listener ports. With this property, we can set the maximum and minimum number of threads used by the message listener service to run the listener ports. This has a direct relationship to the maximum sessions property and, in turn, to the throughput of the MDBs.
How do these properties work together?
Figure 1 shows the relationship between the connection pool, session pool, thread pool and the maximum sessions property.
Figure 1. Relationship between connection factories and the message listener service
Let's look at the specific state of MDBs from Figure 1. The configuration is set up like this:
We have two queue connection factories (QCFs) defined: jms/QCF1 and jms/QCF2. Each has a connection pool where the maximum connections property is set to 2, and a session pool with maximum sessions set to 4. This indicates that for each connection in the connection pool, we will have four sessions in the session pool, indicated in the figure by dotted lines. The message listener service is configured to use a thread pool that has the maximum threads property set to 4. We have two listener ports: ListenerPort1 and ListenerPort2. We have two MDBs: MDB1 and MDB2, which are configured to use ListenerPort1 and ListenerPort2, respectively. ListenerPort1 is configured with maximum sessions set to 2. The JNDI setting for QCF is jms/QCF1. ListenerPort2 is configured with maximum sessions set to 1. The JNDI setting for QCF is jms/QCF2.
Let's review the current state of MDB1.
MDB1 is running with two sessions because the maximum sessions property is set to 2 for ListenerPort1. This causes the MDB to use two threads from the message listener service thread pool to process the messages. Thread1 is using Session1 to deliver the message to one instance of MDB1, and Thread2 is using Session2 to deliver the message to the second instance of MDB1. If there are two messages on the queue when ListenerPort1 starts up, the messages will be processed in parallel.
Suppose we had set maximum sessions to 4. If we have enough threads in the message listener service thread pool, then we will see four threads processing messages in parallel. New MDB instances will get created, and the new threads will be spawned only if so many messages are there on the queue that need to be processed. If the messages arrive on the queue at a very slow pace (for example, one message arrives, then the second one arrive on the queue only after few minutes), we may see only one thread active at any one time.
With this example in mind, it is important to note that:
The listener port will always use one connection from the connection pool for running. This connection will only be released after the listener port has been stopped. Even though the listener port's maximum sessions property is set to a higher value, you might not see that number of sessions processing messages concurrently. If there are not enough free sessions in the session pool -- or enough threads in the message listener service thread pool -- then the number of MDB instances created will be the lowest value of the free threads or free sessions.
In this case, for example, if we set the maximum sessions in ListenerPort1 to 4, there will be only three threads processing in parallel. This is because we have only one thread free in the thread pool, even though we have two free sessions in the session pool (assuming the ListenerPort2 thread for MDB2 is started before the ListenerPort1 thread tried to start; otherwise, MDB2 will not be able to start until one of the MDB1s finishes processing). Sessions used by the listener port thread will be released after they have processed a message (it commits or rolls back). Until that time, the session used by the listener port will not be available to any other application. The throughput of an MDB is directly related to the number of MDB instances started by the listener port thread. If the maximum sessions property is set too high, there will be a large number of MDB instances created, which may affect the application server's performance.
Now, let's look at the current state of MDB2.
MDB2 is configured to use ListenerPort2 with maximum sessions set to 1. This means that the listener port will use Thread3 and Session1 of the jms/QCF2 connection pool to process the message. This is more like sequential processing. Refer to the article Configure WebSphere Application Server to make message-driven beans process messages in a strict order for more detail about accomplishing sequential message processing in a MDB.
Conclusion
This article explained the behavior of the maximum sessions property and its relationship to the message listener service thread pool, connection pool, and session pool. Understanding these pieces and how they work together can be helpful when configuring message-driven beans in WebSphere Application Server to achieve optimal performance.
Resources
About the author  | | | Sanjay M Kesavan has over 11 years of IT experience, having joined IBM in 2000. From that time on, he has been working on WebSphere MQ and WebSphere Application Server, and currently works on the Websphere MQ Java/JMS Level 3 Support team. |
Rate this page
| 
