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 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 the WebSphere MQ queue
has been set to 0.
WebSphere Application Server 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 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.
Considerations
for clustered deployment
When
you are using non-ASF listener ports you can set the default share (DEFSOPT) option
on the queue to exclusive. If you choose this option
when you 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 you can then establish automatic failover for the
application by configuring the following message listener service
custom property in WebSphere Application Server:
- MAX.RECOVERY.RETRIES
- Configure
a high value MAX.RECOVERY.RETRIES on
the message listener services of all the servers in the cluster. The
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. The 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.