Strict message ordering using activation specifications or ASF listener ports connected to IBM MQ v7.x
Strict message ordering can be achieved when deploying message driven bean applications to the IBM MQ messaging provider when no special facilities have been coded into the application to handle messages arriving out of order.
For WebSphere Application Server v7 and later, listener ports are stabilized. We should plan to migrate the IBM 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 Configure activation specifications for non-ASF mode. However, we should not begin this migration until we 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 a later version, we should not migrate applications on that cluster to use activation specifications until after we migrate all the application servers in the cluster to the later version.
The following assumptions have been made in this scenario:
- The message-driven bean (MDB) application is transactional.
- The back-out threshold (BOTHRESH) on the IBM MQ queue has been set to 0.
- We are using IBM MQ v7.0 or later.
WAS configuration for ordered delivery
- The IBM MQ queue manager must be running on IBM MQ v7.0 or later.
- The connection to the queue manager must use the IBM MQ messaging provider normal mode. See the Rules for selecting the IBM MQ messaging provider mode topic of the IBM MQ information center.
- If we are using listener ports Maximum sessions on the listener ports in WAS must be set to 1.
- If we are using activation specifications Maximum server sessions on the activation specifications in WAS must be set to 1.
Important information about this configuration
- ASF listener ports and IBM MQ activation specifications contain two separate parts, which
together perform message delivery. These two parts are seen as separate applications by the queue
manager:
- Part one detects messages as they arrive, but does not consume them. Instead it dispatches them to the second part.
- Part two is a server session pool which allocates a thread to process the message within the application's transaction, and deliver it to the onMessage() method of the DB.
- From v7.0, IBM MQ provides a push model for detection of the messages, which is more efficient than the polling model used in previous versions of IBM MQ, and provides better ordering of message under normal operation.
Circumstances in which messages can be delivered out of order
Messages can be delivered out of order with this configuration in the following circumstances:
- After a transaction rollback, the next message available on the queue might be
delivered before the rolled back message is re-delivered:
- For an ASF listener port, setting Maximum retries to zero prevents out of order delivery after a rollback by stopping the listener port when a rollback occurs. However, the listener port must then be restarted manually.
- For an activation specification, selecting Stop endpoint if message delivery fails and setting Number of sequential delivery failures before suspending endpoint to 0 prevents out of order delivery after a rollback by pausing the message endpoint when a rollback occurs. However, the message endpoint for the MDB must then be resumed manually. See IBM MQ information center.
- Messages can be delivered out of order during a transaction recovery:
A specific set of events must occur in a specific order for this scenario to be encountered, and as such it is uncommon. However, if ordered message delivery is critical to the operation of the application, the consider it.
- Out of order message delivery can occur with this deployment option during recovery from a failure of one of the following components:
- The application server hosting the MDB
- The IBM MQ queue manager
- A network connecting the application server and queue manager
- If one of these components fails in the middle of a two-phase commit of an MDB transaction, the application server transaction manager reestablishes its connection to the queue manager to resolve the transaction when the component is available again.
- This recovery process is asynchronous, and it is possible for delivery of new messages to the DB to begin before the transaction recovery process is complete. If the outcome of the transaction recovery is to roll back the transaction, then the message will be returned to the IBM MQ queue and re-delivered to the application, possibly after new messages have already been delivered.
- Out of order message delivery can occur with this deployment option during recovery from a failure of one of the following components:
Considerations for a clustered deployment
- We must activate the MDB on one cluster member only, as the application server does not have a facility which can manage this activation automatically.
- We can set the startup state of listener ports to stopped, separately to setting the startup state of an application.
- We can manually start and stop applications, ASF listener ports, and message endpoints with Bean interfaces using wsadmin.sh, or using the com.ibm.websphere.management.AdminClient interfaces from Java code.
Related:
