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 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.
The following assumptions have been made in this scenario:
- The message-driven bean (MDB) application is transactional.
- The back-out threshold (BOTHRESH) on the WebSphere MQ queue has been set to 0.
- You are using WebSphere MQ Version
7.0.
WebSphere Application Server configuration
for ordered delivery
- The WebSphere MQ queue manager
must be running on WebSphere MQ version
7.0.
- The connection to the queue manager must use the WebSphere MQ messaging provider normal
mode. See the Rules for selecting the WebSphere MQ messaging
provider mode topic of the WebSphere MQ information
center.
- If you are using listener ports Maximum sessions on
the listener ports in WebSphere Application Server must
be set to 1.
- If you are using activation specifications Maximum
server sessions on the activation specifications in WebSphere Application Server 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:
- 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 MDB.
- WebSphere MQ Version 7.0 provides
a push model for detection of the messages, which is more efficient
than the polling model used in previous versions of WebSphere 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. For more information, see the WebSphere MQ information center.
- Messages can be delivered out of order during a
transaction recovery:
Note: 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 your application, 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 a clustered deployment
- You must activate the MDB on one cluster member only, as the application
server does not have a facility which can manage this activation automatically.
- You can set the startup state of listener ports to stopped, separately
to setting the startup state of an application.
- You can manually start and stop applications, ASF listener ports,
and message endpoints with MBean interfaces by using wsadmin scripting,
or by using the com.ibm.websphere.management.AdminClient interfaces
from Java code.
- In order to configure the startup state of a message endpoint, WebSphere Application Server
Version 7.0 Fix Pack 13 must be installed, as described in APAR PM18782.