Network Deployment (Distributed operating systems), v8.0 > Applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using the WebSphere MQ messaging provider > Strict message ordering with the WebSphere MQ messaging provider and message-driven bean (MDB) applications
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v6.0
Strict message ordering can be achieved when deploying message driven bean applications to the WebSphere MQ messaging provider for when no special facilities have been coded into the application to handle messages arriving out of order.
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.
The following assumptions have been made in this scenario:
- The message-driven bean (MDB) application is transactional.
- The back-out threshold (BOTHRESH) on theWebSphere MQ queue has been set to 0.
- You are using WebSphere MQ v6.0.
WAS configuration for ordered delivery
- If you are using listener ports Maximum sessions on the listener ports in WAS must be set to 1.
- If you 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 WebSphere MQ activation specifications contain two separate parts, which together perform message delivery. These two parts are seen as separate applications by the queue manager:
- One part 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 MDB.
When an ASF listener port or activation specification is connected to a WebSphere MQ v6.0 or earlier queue manager, a less efficient polling mechanism (based on a browse cursor) is used to detect messages on the queue.
Circumstances in which messages can arrive out of order
Messages can arrive out of order with this deployment in the following circumstances:
- 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 WebSphere 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 MDB 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 WebSphere 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:
- 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 the WebSphere MQ information center.
- During normal operation, when multiple threads are sending messages to the destination (for different sequences) using transactions:
- This behavior is due to the operation of the WebSphere MQ browse cursor.
- When a message is committed to a WebSphere MQ queue, while another message sent to the destination is uncommitted (within a transaction that has not yet completed), the browse cursor moves onto the newer message on the queue and does not automatically return to the earlier message when it is eventually committed. This can cause messages to appear in the queue behind the browse cursor.
- If this scenario occurs, newer messages within a sequence might be delivered to the MDB before the WebSphere MQ messaging provider re-scans the queue and detects the message that has appeared behind the browse cursor.
- This behavior is due to the operation of the WebSphere MQ browse cursor.
- If the WebSphere MQ queue being monitored by an activation specification or ASF listener port has the Message delivery sequence attribute (MSGDLYSEQ) set to priority, message ordering can fail due to the following reasons:
- Messages of a lower priority might be delivered ahead of messages of a higher priority, when messages of multiple priorities are sent to a queue, this behavior is due to the operation of the WebSphere MQ browse cursor. The browse cursor moves through all available messages at the highest priority, and then moves to lower priority messages. If higher priority messages arrive when the browse cursor is currently browsing lower priority messages, those higher priority messages might not be delivered until after all lower priority messages on the queue have been delivered.
- ASF listener ports or activation specifications that browse queues that have Message delivery sequence set to FIFO do not see this issue, as WebSphere MQ orders the messages on the queue in the order in which they arrive, rather than ordering them by priority.
Considerations for a clustered deployment
- We can 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 MBean interfaces using wsadmin.sh, or by using the com.ibm.websphere.management.AdminClient interfaces from Java code.
Message-driven beans - listener port components
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v7.0
Message processing in ASF mode and non-ASF mode
Strict message ordering with the WebSphere MQ messaging provider and message-driven bean (MDB) applications
Start a listener port
Start listener ports using scripting
Manage the message endpoint lifecycle using wsadmin.sh
Use wsadmin scripting
Related
Manage message endpoints
Message listener service custom properties
Listener port settings
Performance for WebSphere MQ queues
Stabilized features
WebSphere MQ library
Strict message ordering using non-ASF listener ports
Concept topic