WAS v8.5 > WebSphere applications > Messaging resources > Message-driven beans - automatic message retrievalMessage processing in ASF mode and non-ASF mode
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 WAS processes messages in ASF mode and how it processes messages when ASF mode is turned off.
For WAS v7 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 WAS v7. For example, if we have an application server cluster with some members at v6.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.
Main features of ASF mode
By default, message-driven beans (MDBs) deployed on WAS 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 client connection (socket attach) mode, each active thread is an individual physical network connection. You should keep this in mind when we are deciding whether to use ASF or non-ASF mode in your configuration. If we are using WebSphere MQ v7.x 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 we can use in ASF mode. With the following configurations each thread uses a separate physical network connection:
- A WebSphere MQ v6.0 queue manager.
- A WebSphere MQ v7.x queue manager, using a connection factory that has the Provider version property set to 6.
- A WebSphere MQ v7.x 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 v7.x 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 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 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 we are deciding whether to use ASF or non-ASF mode in your configuration. If we are using WebSphere MQ v7.x 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 we can use in non-ASF mode. With the following configurations each thread uses a separate physical network connection:
- A WebSphere MQ v6.0 queue manager.
- A WebSphere MQ v7.x queue manager, using a connection factory that has the Provider version property set to 6.
- A WebSphere MQ v7.x 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 v7.x 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.
Non-ASF mode cannot be selected on z/OS systems.
Subtopics
- 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 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.- How messages are processed in non-ASF mode
In non-ASF mode threads are active from the moment 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 available to be processed. Each active thread is an individual physical network connection.
Related concepts:
Strict message ordering using non-ASF listener ports
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v6.0
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v7.x
Related
Configure transaction properties for an application server
Reference:
Message listener service custom properties
WebSphere MQ messaging provider connection factory settings
WebSphere MQ messaging provider queue connection factory settings
WebSphere MQ messaging provider topic connection factory settings
Listener port settings
Stabilized features