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 WebSphere Application Server Version 7 and later, listener ports are stabilized. For more information, read the topic about stabilized features. 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 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 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 Version
6.0.
WebSphere Application Server configuration
for ordered delivery
- 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
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:
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, 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.
- 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
documentation.
- 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 following 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.
- 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
- You can 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.