[Updated in August 2011]

Message processing in 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.

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. 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 Version 7, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to Version 7.

Note: If you are using WebSphere MQ as your messaging provider, in the examples in this topic, JMS provider refers to your WebSphere MQ queue manager.

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 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.

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.0 queue manager, using a connection factory that has the Provider version property set to 6.
  • A WebSphere MQ Version 7.0 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.0 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.

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 default value for Maximum Sessions on listener ports is 1. This means that the MDB can only process one message at a time. The example shows how messages are processed in ASF mode when Maximum Sessions is set to 1:
  1. When the listener port is started, it opens a connection to the JMS provider and creates an internal queue agent.
  2. The queue agent listens to the JMS destination for messages.
  3. The queue agent detects a message and checks whether it is suitable for the MDB that is using the listener port.
  4. If the message is suitable for the MDB, the queue agent passes the message ID into a work record. The work record is then sent to the workload management (WLM) queue.
  5. The queue agent starts listening for messages again.
  6. The WLM queue starts an ASF dispatcher inside a servant region to process the work record.
  7. The ASF dispatcher allocates a server session from the server session pool.
  8. The server session use the message ID from the work record to retrieve the message from the destination.
  9. The server session processes the message by calling the onMessage() method of the MDB.
  10. When the message is processed, the server session exits and returns to the application server session pool. The connection that the server session has opened to the JMS provider remains open so that the server session does not need to re-establish the connection the next time it is used.
  11. The thread exits and returns to the message listener service thread pool.

The following diagram shows how messaging takes place between WebSphere Application Server and WebSphere MQ in ASF mode, with Maximum Sessions set to 1. The numbers on the diagram correspond to the numbers in the list.

This diagram shows how messaging takes place between WebSphere Application Server and WebSphere MQ in ASF mode, with Maximum Sessions set to 1. The numbers on the diagram correspond to the numbers in the list.
ASF mode enables you to process more than one message concurrently. To do this, set Maximum Sessions to a value higher than 1. If, for example, Maximum Sessions is set to 2, messages are processed in the following way:
  1. The queue agent detects the first message and sets up a work record, as in the first example.
  2. The work record is sent to the WLM queue and an ASF dispatcher is set up in a servant region.
  3. The ASF dispatcher allocates a server session and the message is processed using the onMessage() method of the MDB.
  4. Whilst the first message is processing, the queue agent starts listening for messages again.
  5. The queue agent detects the second message and allocates a second thread and a second server session. The message is processed using the onMessage() method of the MDB.
  6. When the first message is processed, the first server session exits and returns to the server session pool. The first thread exits and returns to the thread pool.
  7. When the second message is processed, the second server session exits and returns to the server session pool. The second thread exits and returns to the thread pool.



Related concepts
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.0
Related 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
Concept topic Concept topic    

Terms of Use | Feedback

Last updatedLast updated: Sep 19, 2011 3:08:41 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-zos&topic=cmb_asfnonasf
File name: cmb_asfnonasf.html


[Updated in August 2011]
aug2011