Application Server Facilities (ASF) mode is the default
method by which the message listener service in WebSphere® Application Server processes messages.
This topic explains how WebSphere Application Server processes
messages in ASF mode and how it processes
messages when ASF mode is turned off.
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 Version 7, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to Version 7.
Note: If you are using WebSphere MQ as
your messaging provider, in the examples in this topic, JMS provider
refers to your WebSphere MQ queue
manager.
Main features of ASF mode
By default, message-driven
beans (MDBs) that are deployed on WebSphere Application Server for use with listener
ports, use ASF mode to monitor JMS destinations and to process messages.
In ASF mode, a thread is allocated for work
when a message is detected at the destination for it to process. The
number of threads that can be active concurrently is dictated by the
value specified for the Maximum Sessions property
for the listener port.
In ASF mode, a thread
is allocated for work when a message is detected at the destination
for it to process. The number of work records that can be held on
the workload management (WLM) queue is dictated by the value specified
for the Maximum Sessions property for the listener
port.
In client connection (socket attach)
mode, each active thread is an individual physical network connection.
You should keep this in mind when you are deciding whether to use
ASF or non-ASF mode in your configuration. If you are using WebSphere MQ Version 7.0 as your messaging
provider, it is possible to have up to ten threads sharing a single
physical network connection.
If
WebSphere MQ is your messaging provider,
there are several configurations you can use in ASF mode. With the
following configurations each thread uses a separate physical network
connection:
- A WebSphere MQ Version 6.0 queue
manager.
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 6.
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 7 or unspecified,
connecting over a WebSphere MQ channel
that has the SHARECNV (sharing conversations)
parameter set to 0.
With the following configuration, threads share a user-defined
number of physical network connections:
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 7 or unspecified,
connecting over a WebSphere MQ channel
that has the SHARECNV (sharing conversations)
parameter set to 1 or higher. In this case
each thread represents an individual connection to a queue manager.
However, each thread does not have its own physical network connection,
Instead, the threads share the number of network connections specified
in the SHARECNV (sharing conversations) parameter.
Main features of non-ASF mode
In
non-ASF mode threads are active from the moment that the listener
port is turned on. The number of active threads is dictated by the
value specified for the Maximum Sessions property
on the listener port. The number of threads specified in Maximum
Sessions are active, regardless of the number of messages
that are available to be processed.
In non-ASF mode, when a
listener port browses for messages at the destination, it will take
the message that is first in the queue at the destination for processing.
This means that messages are processed close to the order in which
they arrive at the destination.
In client connection (socket
attach) mode, each active thread is an individual physical network
connection. You should keep this in mind when you are deciding whether
to use ASF or non-ASF mode in your configuration. If you are using WebSphere MQ Version 7.0 as your messaging
provider, it is possible to have up to ten threads sharing a single
physical network connection.
If
WebSphere MQ is your messaging provider,
there are several configurations you can use in non-ASF mode. With
the following configurations each thread uses a separate physical
network connection:
- A WebSphere MQ Version 6.0 queue
manager.
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 6.
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 7 or unspecified,
connecting over a WebSphere MQ channel
that has the SHARECNV (sharing conversations)
parameter set to 0.
With the following configuration, threads share a user-defined
number of physical network connections:
- A WebSphere MQ Version 7.0 queue
manager, using a connection factory that has the Provider
version property set to 7 or unspecified,
connecting over a WebSphere MQ channel
that has the SHARECNV (sharing conversations)
parameter set to 1 or higher. In this case
each thread represents an individual connection to a queue manager.
However, each thread does not have its own physical network connection.
Instead, the threads share the number of network connections specified
in the SHARECNV (sharing conversations) parameter.
Note: Non-ASF mode cannot be selected on z/OS systems.
How messages are processed in ASF mode
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 default value for
Maximum
Sessions on listener ports is
1.
This means that the MDB can only process one message at a time. The
example shows how messages are processed in ASF mode when
Maximum
Sessions is set to
1:
- When the listener port is started, it opens a connection to the
JMS provider 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 is processed, the server session exits and returns
to the application server session pool. The connection that the server
session has 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 following diagram shows how
messaging takes place between WebSphere Application Server and WebSphere
MQ in ASF mode, with Maximum Sessions set to 1.
The numbers on the diagram correspond to the numbers in the list.

The default value for
Maximum
Sessions on listener ports is
1.
This means that the MDB can only process one message at a time. The
example shows how messages are processed in ASF mode when
Maximum
Sessions is set to
1:
- When the listener port is started, it opens a connection to the
JMS provider and creates an internal queue agent.
- The queue agent listens to the JMS destination for messages.
- The queue agent detects a message and checks whether it is suitable
for the MDB that is using the listener port.
- If the message is suitable for the MDB, the queue agent passes
the message ID into a work record. The work record is then sent to
the workload management (WLM) queue.
- The queue agent starts listening for messages again.
- The WLM queue starts an ASF dispatcher inside a servant region
to process the work record.
- The ASF dispatcher allocates a server session from the server
session pool.
- The server session use the message ID from the work record to
retrieve the message from the destination.
- The server session processes the message by calling the onMessage() method
of the MDB.
- When the message is processed, the server session exits and returns
to the application server session pool. The connection that the server
session has 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 following diagram shows how messaging
takes place between WebSphere Application Server and WebSphere MQ
in ASF mode, with Maximum Sessions set to 1.
The numbers on the diagram correspond to the numbers in the list.

ASF mode enables you
to process more than one message concurrently. To do this, set
Maximum
Sessions to a value higher than
1.
If, for example,
Maximum Sessions is set 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.
ASF mode enables you to process more than
one message concurrently. To do this, set
Maximum Sessions to
a value higher than
1. If, for example,
Maximum
Sessions is set to
2, messages are
processed in the following way:
- The queue agent detects the first message and sets up a work record,
as in the first example.
- The work record is sent to the WLM queue and an ASF dispatcher
is set up in a servant region.
- The ASF dispatcher allocates a server session and 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.
How messages are processed
in non-ASF mode
In non-ASF mode threads are active from
the moment that the listener port is started. The number of active
threads is dictated by the value specified for Maximum Sessions.
The number of threads specified in Maximum Sessions are
active, regardless of the number of messages that are available to
be processed. Each active thread is an individual physical network
connection. If you are using WebSphere MQ Version
7.0 as your messaging provider, it is possible to have up to ten threads
sharing a single physical network connection.
To activate non-ASF
mode you must specify a non-zero value for the NON.ASF.RECEIVE.TIMEOUT message
listener service custom property. The NON.ASF.RECEIVE.TIMEOUT custom
property acts as a switch that turns off ASF mode, and also as a timeout
value for the receive() method.
The
following message listener service custom properties do not work in
non-ASF mode:
- SERVER.SESSION.POOL.REAP
- SERVER.SESSION.POOL.UNUSED.TIMEOUT
- SERVER.SESSION.POOL.UNUSED.TIMEOUT.Ipaname
The default value for
Maximum Sessions is
1.
This means that the MDB can only process one message at a time. Non-ASF
mode processes messages in the following way when
Maximum
Sessions is set to
1:
- When the listener port is started, it gets one thread from the
message listener service thread pool.
- The listener port opens a connection to the JMS provider on the
thread and creates a JMS message consumer. The message consumer listens
to the JMS destination which the listener port is configured to listen
to.
- The listener port creates a transaction to manage the message
processing.
- The thread calls the receive() method
on the message consumer to listen for messages at the destination.
If the receive() method does not
detect a message in the time specified for NON.ASF.RECEIVE.TIMEOUT,
the application server rolls back the active transaction and starts
a new one. The thread then starts calling the receive() method
again.
- When the message consumer detects a message it checks whether
the message is suitable for the MDB that is using the listener port.
- If the message is suitable, the receive() method
takes it off the destination and sends it to the thread.
- The thread invokes the onMessage() method
of the MDB on the message consumer, and the message is processed.
- If the message finishes processing successfully, the transaction
commits. If the message does not process successfully, the transaction
rolls back.
- A new transaction is started and the message consumer calls the receive() method
to listen for new messages.
The following diagram shows how
messaging takes place between WebSphere Application Server and WebSphere
MQ in non-ASF mode, with Maximum Sessions set
to 1. The numbers on the diagram correspond
to the numbers in the example list.

Non-ASF mode enables you to process more than
one message at once. To do this, set
Maximum Sessions to
a value higher than
1. If, for example,
Maximum
Sessions is set to
2, messages are
processed in the following way:
- When the listener port is started, it gets two threads from the
message listener service thread pool.
- The listener port creates a message consumer and a transaction
on each thread. The message consumers listen to the destination which
the listener port is configured to listen to.
- Both message consumers call the receive() method
to listen for messages on the destination. The consumers compete to
get messages from the destination.
- When one of the consumers successfully retrieves the message,
it processes it by calling the onMessage() method
of the MDB. The other message consumer keeps on calling the receive() method
to listen for messages on the destination.
If your messaging system is running in non-ASF
mode, to avoid unwanted transaction timeouts, you must allow a sufficient
amount of time for processing to be completed before the total transaction
lifetime timeout is reached. Therefore, you must make sure that the
value that you specify for the NON.ASF.RECEIVE.TIMEOUT message
listener service custom property is smaller than the value that you
specify for the Total transaction lifetime timeout transaction
service property, and also that the difference between the values
of the two properties is greater than the amount of time that the onMessage() method
of the message-driven bean (MDB) takes to process the message.
As the following example shows, if these properties
are not correctly configured, transactions can time out before they
are completed. This is because the thread begins calling the
receive() method
as soon as the transaction is created. In the following example,
NON.ASF.RECEIVE.TIMEOUT is
set to
110000 milliseconds (110 seconds),
Total
transaction lifetime timeout is set to
120 seconds
and the onMessage () method of the MDB takes 15 seconds to process
a message. The example supposes that a message does not appear at
the destination until the
receive() method
has almost timed out:
- The listener port starts. It allocates a thread from the thread
pool and creates a transaction and a message consumer on the thread.
- The thread calls the receive() method
to listen for messages.
- After 110 seconds a message appears at the destination.
- The thread removes the message from the destination and calls
the onMessage() method of the
MDB to begin processing the message.
- 10 seconds later, the transaction timeout is reached. The application
server marks the transaction for rollback.
- 5 seconds later, the onMessage() method
finishes processing the message and tries to commit the transaction.
- The total amount of time that has elapsed since the transaction
was started is 125 seconds (110 seconds waiting for a message, plus
15 seconds to process the message). As this is longer than the transaction
timeout, the application server prevents the transaction from being
committed, and it is rolled back.
For further information about how to configure
the NON.ASF.RECEIVE.TIMEOUT and Total
transaction lifetime timeout properties to avoid unwanted
transaction time outs, see the related tasks.