Message processing in ASF mode![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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 your 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 Configuring 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 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.
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 IBM MQ Version 7.x as your messaging provider, it is possible to have
up to ten threads sharing a single physical network connection.
- A IBM MQ Version 6.0 queue manager.
- A IBM MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 6.
- A IBM MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over a IBM MQ channel that has the SHARECNV (sharing conversations) parameter set to 0.
- A IBM MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over a 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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 IBM MQ Version 7.x as your messaging provider, it is possible to have up to ten threads sharing a single physical network connection.
- A IBM MQ Version 6.0 queue manager.
- A IBM MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 6.
- A IBM MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over a IBM MQ channel that has the SHARECNV (sharing conversations) parameter set to 0.
- A IBM MQ Version 7.x queue manager, using a connection factory that has the Provider version property set to 7 or unspecified, connecting over a 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.