Message processing in ASF mode[AIX Solaris HP-UX Linux Windows][IBM i] 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[AIX Solaris HP-UX Linux Windows][IBM i] 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 topic about stabilized features. 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 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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.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 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.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.
[AIX Solaris HP-UX Linux Windows][IBM i]

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.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 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.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.
Note: Non-ASF mode cannot be selected on z/OS systems.