In
ASF mode, server sessions and threads are only allocated
for work when a message that is suitable for the message-driven bean
(MDB) is detected. The number of threads that an MDB can process concurrently
is determined by the value of the Maximum Sessions property
for the listener port.
For WebSphere® Application Server Version 7 and later, listener ports are stabilized. For more information, read the article on stabilized features. You should plan to migrate your WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. However, you should not begin this migration until you are sure the application does not have to work on application servers earlier than WebSphere Application Server Version 7. For example, if you have an application server cluster with some members at Version 6.1 and some at a later version, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to the later version.
The following diagram shows how
messaging takes place between
WebSphere Application Server and
WebSphere MQ when the message listener
service is operating in ASF mode.
Figure 1. Message processing in
ASF mode on distributed and IBM i systems
As
shown in the diagram, when the message
listener service is operating in ASF mode, messages are processed
in the following way:
- When the listener port is started, it
opens a connection to the WebSphere MQ queue
manager and creates
an internal queue agent.
- The queue agent listens to the JMS
destination for messages.
- The queue agent detects a message.
- The queue agent checks whether the message is suitable for the
MDB that is using the listener port.
- If the message is suitable
for the MDB, the listener port allocates
a thread from the message listener service thread pool, and allocates
a server session from the application server's server session pool.
If this is the first time the server session has been used since the
listener port has been started, it opens a connection to the JMS provider.
The allocated server session runs on the allocated thread.
- The
queue agent passes the ID of the message to the server session.
It then starts listening for messages again.
- The server session
uses the message ID to retrieve the message
from the destination.
- The server session processes the message
by calling the onMessage() method
of the MDB.
- When the message has been processed, the server
session exits
and returns to the application server session pool. The connection
that the server session opened to the JMS provider remains open so
that the server session does not need to re-establish the connection
the next time it is used.
- The thread exits and returns to
the message listener service thread
pool.
The number of threads that an MDB can process
concurrently
is determined by the value of the Maximum Sessions property
for the listener port. If you set Maximum Sessions to
the default value of 1, this means that the
MDB can only process one message at a time. Therefore, if the queue
agent finds a second message before the first message has finished
being processed, the queue agent blocks the second message until processing
of the first message is complete and the server session has become
available.
If you want to process more than one message concurrently,
you can do this in ASF mode by setting
Maximum Sessions to
a value higher than
1. For example, if you
set
Maximum Sessions to
2,
messages are processed in the following way:
- The queue agent
detects the first message and allocates a thread
and a server session as in the first example. The message is processed
using the onMessage() method of
the MDB.
- Whilst the first message is processing, the queue
agent starts
listening for messages again.
- The queue agent detects the
second message and allocates a second
thread and a second server session. The message is processed using
the onMessage() method of the
MDB.
- When the first message is processed, the first server
session
exits and returns to the server session pool. The first thread exits
and returns to the thread pool.
- When the second message is
processed, the second server session
exits and returns to the server session pool. The second thread exits
and returns to the thread pool.