Message 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 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 the WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. For more information about how to configure activation specifications for non-ASF mode, see Configure activation specifications for non-ASF mode. 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 we 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.
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.
(zos) 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 we are deciding whether to use ASF or non-ASF mode in the configuration. If we are using WebSphere MQ Version 7.x as the messaging provider, it is possible to have up to ten threads sharing a single physical network connection.
If WebSphere MQ is the 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 Version 6.0 queue manager.
- A WebSphere MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 6.
- A WebSphere MQ Version 7.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 Version 7.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 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 we are deciding whether to use ASF or non-ASF mode in the configuration. If we are using WebSphere MQ Version 7.x as the messaging provider, it is possible to have up to ten threads sharing a single physical network connection.
If WebSphere MQ is the 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 Version 6.0 queue manager.
- A WebSphere MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 6.
- A WebSphere MQ Version 7.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 Version 7.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 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.
- 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.
Related concepts
Strict message ordering using non-ASF listener ports
(zos) Messaging flow for ASF message-driven beans with WebSphere MQ as the messaging provider
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ Version 6.0 Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ Version 7.x
Related tasks
Configure transaction properties for an application server
Configure activation specifications for non-ASF mode
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