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 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. However, we should plan to migrate IBM MQ MDB deployment configurations from listeners to activation specifications. Activation specifications are the standardized way to manage and configure the relationship between a message driven bean (MDB) running in WebSphere Application Server and a destination in IBM MQ. Do not begin this migration for application running on application servers earlier than WAS v7.
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.
(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. We should keep this in mind when we are deciding whether to use ASF or non-ASF mode in the configuration. If we are using IBM MQ v7.x as our messaging provider, it is possible to have up to ten threads sharing a single physical network connection.
If IBM MQ is our messaging provider, there are several configurations we can use in ASF mode. With the following configurations each thread uses a separate physical network connection:
- An IBM MQ v6.0 queue manager.
- An IBM MQ v7.x queue manager, using a connection factory that has the Provider version property set to 6.
- An IBM MQ v7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over an IBM 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:
- An IBM MQ v7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over an IBM 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. We should keep this in mind when we are deciding whether to use ASF or non-ASF mode in the configuration. If we are using IBM MQ v7.x as our messaging provider, it is possible to have up to ten threads sharing a single physical network connection.
If IBM MQ is our 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:
- An IBM MQ v6.0 queue manager.
- An IBM MQ v7.x queue manager, using a connection factory that has the Provider version property set to 6.
- An IBM MQ v7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over an IBM 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:
- An IBM MQ v7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over an IBM 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
Related:
Strict message ordering using non-ASF listener ports (ZOS) Messaging flow for ASF message-driven beans with IBM MQ as the messaging provider Strict message ordering using activation specifications or ASF listener ports connected to IBM MQ v6.0 Strict message ordering using activation specifications or ASF listener ports connected to IBM MQ v7.x Configure transaction properties for an application server Configure activation specifications for non-ASF mode Message listener service custom properties IBM MQ messaging provider connection factory settings IBM MQ messaging provider queue connection factory settings IBM MQ messaging provider topic connection factory settings Listener port settings Stabilized features of WAS traditional