Network Deployment (Distributed operating systems), v8.0 > Applications > Messaging resources > Message-driven beans - automatic message retrieval File name: cmb_asfnonasf.html


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 WAS 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. 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 WAS v7. For example, if we have an application server cluster with some members at v6.1 and some at v7, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to v7.

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

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 the configuration. If you are using WebSphere MQ v7.0 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:

With the following configuration, threads share a user-defined number of physical network connections:


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 the configuration. If you are using WebSphere MQ v7.0 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:

With the following configuration, threads share a user-defined number of physical network connections:

Non-ASF mode cannot be selected on z/OS systems.


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.
  4. The queue agent checks whether the message is suitable for the MDB that is using the listener port.

  5. If the message is suitable for the MDB, the listener port allocates a thread from the message listener service thread pool, and allocates a server session from the application server's server session pool. If this is the first time the server session has been used since the listener port has been started, it opens a connection to the JMS provider. The allocated server session runs on the allocated thread.
  6. The queue agent passes the ID of the message to the server session. It then starts listening for messages again.
  7. The server session uses the message ID to retrieve the message from the destination.
  8. The server session processes the message by calling the onMessage() method of the MDB.

  9. 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.
  10. The thread exits and returns to the message listener service thread pool.

The following diagram shows how messaging takes place between WAS 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 allocates a thread and a server session as in the first example. The message is processed using the onMessage() method of the MDB.
  2. Whilst the first message is processing, the queue agent starts listening for messages again.
  3. 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.

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

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


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. If you are using WebSphere MQ v7.0 as your messaging provider, it is possible to have up to ten threads sharing a single physical network connection.

To activate non-ASF mode specify a non-zero value for the NON.ASF.RECEIVE.TIMEOUT message listener service custom property. The NON.ASF.RECEIVE.TIMEOUT custom property acts as a switch that turns off ASF mode, and also as a timeout value for the receive() method.

The following message listener service custom properties do not work in non-ASF mode:

The default value for Maximum Sessions is 1. This means that the MDB can only process one message at a time. Non-ASF mode processes messages in the following way when Maximum Sessions is set to 1:

  1. When the listener port is started, it gets one thread from the message listener service thread pool.
  2. The listener port opens a connection to the JMS provider on the thread and creates a JMS message consumer. The message consumer listens to the JMS destination which the listener port is configured to listen to.
  3. The listener port creates a transaction to manage the message processing.
  4. The thread calls the receive() method on the message consumer to listen for messages at the destination. If the receive() method does not detect a message in the time specified for NON.ASF.RECEIVE.TIMEOUT, the application server rolls back the active transaction and starts a new one. The thread then starts calling the receive() method again.

  5. When the message consumer detects a message it checks whether the message is suitable for the MDB that is using the listener port.

  6. If the message is suitable, the receive() method takes it off the destination and sends it to the thread.
  7. The thread invokes the onMessage() method of the MDB on the message consumer, and the message is processed.

  8. If the message finishes processing successfully, the transaction commits. If the message does not process successfully, the transaction rolls back.
  9. A new transaction is started and the message consumer calls the receive() method to listen for new messages.

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

Non-ASF mode enables you to process more than one message at once.

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. When the listener port is started, it gets two threads from the message listener service thread pool.
  2. The listener port creates a message consumer and a transaction on each thread. The message consumers listen to the destination which the listener port is configured to listen to.
  3. Both message consumers call the receive() method to listen for messages on the destination. The consumers compete to get messages from the destination.

  4. When one of the consumers successfully retrieves the message, it processes it by calling the onMessage() method of the MDB. The other message consumer keeps on calling the receive() method to listen for messages on the destination.

If your messaging system is running in non-ASF mode, to avoid unwanted transaction timeouts, make sure that the time that you specify for the NON.ASF.RECEIVE.TIMEOUT message listener service custom property is smaller than the sum of the maximum amount of time that the onMessage() method of the message-driven bean (MDB) takes to process the message, plus the time you specify for the Total transaction lifetime timeout transaction service property.

If these properties are not correctly configured, transactions can time out before they are completed. This is because the thread begins calling the receive() method as soon as the transaction is created. In the following example, NON.ASF.RECEIVE.TIMEOUT is set to 110000 milliseconds (110 seconds), Total transaction lifetime timeout is set to 120 seconds and the onMessage () method of the MDB takes 15 seconds to process a message. The example supposes that a message does not appear at the destination until the receive() method has almost timed out:

  1. The listener port starts. It allocates a thread from the thread pool and creates a transaction and a message consumer on the thread.
  2. The thread calls the receive() method to listen for messages.

  3. After 110 seconds a message appears at the destination.
  4. The thread removes the message from the destination and calls the onMessage() method of the MDB to begin processing the message.
  5. 10 seconds later, the transaction timeout is reached. The application server marks the transaction for rollback.
  6. 5 seconds later, the onMessage() method finishes processing the message and tries to commit the transaction.
  7. The total amount of time that has elapsed since the transaction was started is 125 seconds (110 seconds waiting for a message, plus 15 seconds to process the message). As this is longer than the transaction timeout, the application server prevents the transaction from being committed, and it is rolled back.

For further information about how to configure the NON.ASF.RECEIVE.TIMEOUT and Total transaction lifetime timeout properties to avoid unwanted transaction time outs, see the related tasks.
Strict message ordering using non-ASF listener ports
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v6.0
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v7.0
Configure transaction properties for an application server
Avoiding transaction timeouts in non-ASF mode


Related


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

aug2011

+

Search Tips   |   Advanced Search