WAS v8.5 > WebSphere applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using the WebSphere MQ messaging provider > Strict message ordering with the WebSphere MQ messaging provider and MDB applicationsStrict message ordering using non-ASF listener ports
Strict message ordering can be achieved when deploying message driven bean applications to the WebSphere MQ messaging provider 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 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.
The following assumptions have been made in this scenario:
- The MDB application is transactional.
- The back-out threshold (BOTHRESH) on the WebSphere MQ queue has been set to 0.
WAS configuration for ordered delivery
- Non-ASF mode must be activated by specifying a non-zero timeout value for the NON.ASF.RECEIVE.TIMEOUT WebSphere MQ message listener service custom property.
- The Maximum sessions setting for the listener port must be set to 1.
- A non-ASF listener port with Maximum sessions set to 1 has a single thread running inside the application server retrieving messages. When a message arrives the thread immediately delivers it to the MDB.
- The queue manager regards this thread as a single application retrieving messages, therefore messages are processed in sequence.
Messages can be delivered out of order with this deployment 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 you must 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.
Considerations for clustered deployment
When using non-ASF listener ports we can set the default share (DEFSOPT) option on the queue to exclusive. If we choose this option when we are performing a clustered deployment of an application, all but one of the cluster members fail to start their listener ports. The cluster members generate a 2042MORC_OBJECT_IN_USE exception, in a WMSG0057E message.
When this exception occurs we can then establish automatic failover for the application by configuring the following message listener service custom property in WAS:
- MAX.RECOVERY.RETRIES
- Configure a high value MAX.RECOVERY.RETRIES on the message listener services of all the servers in the cluster. Maximum value for MAX.RECOVERY.RETRIES is 2147483647.
- The MAX.RECOVERY.RETRIES message listener service custom property must be accompanied by a suitable MAX.RECOVERY.INTERVAL message listener service custom property. Maximum amount of time a listener port can retry without being manually stopped and restarted is 2147483647 times the value specified for MAX.RECOVERY.INTERVAL. In this configuration each cluster member continuously attempts to start its listener port, until the active cluster member stops and the queue manager allows it to connect as a single exclusive consumer.
Related concepts:
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v7.x
Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ v6.0
Message processing in ASF mode and non-ASF mode
Related
Start a listener port
Start listener ports using scripting
Manage the message endpoint lifecycle using wsadmin.sh
Manage message endpoints
Tune messaging destinations for the WebSphere MQ messaging provider
Use wsadmin scripting
Avoiding transaction timeouts in non-ASF mode
Reference:
Message listener service custom properties
Message-driven beans - listener port components
Listener port settings
WebSphere MQ library
Stabilized features