Delivery ordering with the WebSphere MQ mesaging provider and message-driven bean (MDB) applications

Technote (FAQ)


Question

What level of JMS message delivery ordering is available for message-driven bean (MDB) applications, running in WebSphere Application Server, consuming from WebSphere MQ?

Cause

Some application designs require that each message arriving within a sequence is processed in the exact order it arrived on the queue. WebSphere MQ provides a set of conditions for sequential delivery in the Sequential retrieval of messages topic of the WebSphere MQ Information Center.
The last condition is "Only one application is doing get operations to retrieve the messages from the destination queue. If this is not the case, these applications must be designed to get all the messages in each sequence put by a sending application.".

This technote describes how this condition applies to the various options for deploying MDB applications to the WebSphere MQ messaging provider for WebSphere Application Server, when no special facilities have been coded in the application to handle messages arriving out of order.


Answer

The following deployment options for MDB applications provide some level of ordered delivery.
The circumstances in which messages might arrive out of order is described in each case.

The MDB application is assumed to be transactional, and it is assumed that the back-out threshold (BOTHRESH) has been configured to zero on the WebSphere MQ queue.

1. Non-ASF listener port
Not available in WebSphere Application Server for z/OS.
Configuration requirements for ordered delivery

  • See the NON.ASF.RECEIVE.TIMEOUT property in the Message listener service custom properties section of the WebSphere Application Server information center for details of enabling non-ASF mode
  • The "Maximum sessions" setting of the listener port must be set to 1
Summary
    A non-ASF listener port, with maximum sessions set to 1, has a single thread running inside the application server polling for messages, and immediately delivering them to the MDB on that thread as they arrive. From the queue manager's perspective, this thread is a single application performing get operations, so fully satisfies the condition for sequential retrieval of messages.
Circumstances in which messages might be delivered out of order
  • Only during a transaction recovery scenario. See detailed description on this scenario below.
Considerations for clustered deployment
    When using non-ASF mode, it is possible to set the default share option (DEFSOPT) on the queue to exclusive. With this option set for a clustered deployment of an application, all except one of the cluster members will fail to start their listener ports with a 2042 MQRC_OBJECT_IN_USE error (in a WMSG0057E msg).
    It is then possible to establish automatic fail-over of the application by configuring a large MAX.RECOVERY.RETRIES setting (with a suitable RECOVERY.RETRY.INTERVAL) on the message listener service of all servers in the cluster. As a result, each cluster member will continuously attempt to start its listener port, until the active cluster member stops and the queue manager allows it to connect as the single exclusive consumer.
    MAX.RECOVERY.RETRIES and RECOVERY.RETRY.INTERVAL are both Message Listener Service Custom Properties, and should be set in the same way as the NON.ASF.RECEIVE.TIMEOUT. property.
    Note that MAX.RECOVERY.RETRIES cannot be set to an infinite value, the maximum is 2147483647. So the longest that the listener port can be left retrying without manually stopping+restarting is 2147483647 times the configured RECOVERY.RETRY.INTERVAL.


2. Activation specification or ASF listener port connected to WebSphere MQ Version 7.0
WebSphere MQ messaging provider activation specifications are not available in WebSphere Application Server Version 6.0 and Version 6.1. Listener ports must be used in these environments.
Configuration requirements for ordered delivery
  • The WebSphere MQ queue manager is Version 7.0
  • In WebSphere Application Server Version 6.0 and 6.1, the MQ_INSTALL_ROOT WebSphere variable points at a WebSphere MQ Version 7.0 client or server installation on the local machine.
  • The WebSphere MQ messaging provider normal mode is enabled for the WebSphere MQ Version 7.0 JCA resource adapter, not the migration mode.
    See the Rules for selecting the WebSphere MQ messaging provider mode topic of the WebSphere MQ information center for further information.
  • The "Maximum sessions" setting of a listener port must be set to 1
  • The "Maximum server sessions" setting of an activation specification must be set to 1
Summary
    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 (a server session pool) which allocates a thread to consume 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 might be delivered out of order
  • 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 the "Maximum retries" property 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 administratively.
      See the Starting a listener port and Starting listener ports using scripting topics in the WebSphere Application Server information center for information on starting listener ports.
    • 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 administratively.
      See the Manage message endpoints and Managing the message endpoint lifecycle using wsadmin scripting topics in the WebSphere Application Server information center for information on resuming message endpoints.
  • During a transaction recovery scenario. See detailed description on this scenario below.
Considerations for clustered deployment
    The MDB must only be activated on one cluster member. Please note there is no facility provided by the application server to to manage activation on a single cluster instance automatically.
    By default the application server cluster will activate the ASF Listener Port or Activation Specification endpoint on all servers in the cluster. The startup state of a listener ports can be set to stopped, separately to the startup state of an application. WebSphere Application Server Version 7.0 fix pack 7.0.0.13 is required in order to configure the startup state of a message endpoint, as described in APAR PM18782.
    Facilities are also provided by the application server to allow applications, ASF listener ports and message endpoints to be administratively started and stopped via code, using with MBean interfaces. The code might be wsadmin scripting, or Java code using the com.ibm.websphere.management.AdminClient interfaces.
    Any script/code that uses the MBean interfaces to monitor/manage activation of the MDB across cluster members would need to be written by the user. Please see the "Non-ASF listener port" section above for an alternative on distribution platforms.

3. Activation specification or ASF listener port connected to WebSphere MQ Version 6.0
Configuration requirements for ordered delivery
  • The "Maximum sessions" setting of a listener port must be set to 1
  • The "Maximum server sessions" setting of an activation specification must be set to 1
Summary
    When an ASF listener port or activation specification is connected to a WebSphere MQ Version 6.0 or earlier queue manager, a less efficient polling mechanism (based on a browse cursor) is used to detect messages on the queue. Otherwise, operation occurs in the same two part mode described above for connecting to WebSphere MQ Version 7.0 queue managers.
    The WebSphere MQ Version 6.0 mode of operation is also enabled when a WebSphere MQ Version 6.0 or earlier JMS client is used to connect to a WebSphere MQ Version 7.0 queue manager, or when the "Provider version" is set to 6.0.0.0 with a WebSphere MQ Version 7.0 JMS client.
Circumstances in which messages might be delivered out of order
  • The rollback and recovery scenarios described for ASF listener port or activation specification connected to WebSphere MQ Version 7.0 apply equally in this mode of operation.
  • Messages within a sequence might be delivered in an unexpected order 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. e.g. messages can appear on the queue behind the browse cursor.
    Once this scenario has occurred, newer messages within a sequence might be delivered to the MDB before the WebSphere MQ JMS client re-scans the queue and detects the message that 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, 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 also 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 while the browse cursor is current 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 the "Message delivery sequence" attribute set to FIFO will not see this issue, as WebSphere MQ will order the messages on the queue in the order in which they arrive, rather than ordering them by priority.
Considerations for clustered deployment
    The considerations are the same as for for ASF listener port or activation specification connected to WebSphere MQ Version 7.0.


Out of order delivery in a transaction recovery scenario
    All of the above deployment options have an additional possibility for out of order delivery, when recovering 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's transaction, the application server's transaction manager will reestablish its connection to the queue manager to resolve the transaction once 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 rollback 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.
    A specific set of events have to occur in a specific order for this scenario to be encountered, and as such it is uncommon. However, if the order of delivery of messages to an application is critical to the operation of that application, then it might need to be considered.


4. Exploiting the strict message ordering facility of the default messaging provider
Configuration requirements for ordered delivery
  • A Service Integration Bus, with a WebSphere MQ link between the WebSphere MQ queue manager hosting the queue and the bus.
    See the Bus configurations section of the WebSphere Application Server information center for details of configuring a bus for the default messaging provider.
  • If a mixture of persistent and nonpersistent messages might be sent within an ordered sequence, the non-persistent message speed (NPMSPEED) on the WebSphere MQ sender channel is set to NORMAL.
  • A destination configured in the bus with the "Strict message ordering" checkbox ticked, which the MDB application will consume from via a default messaging provider activation specification.
    See the Strict message ordering for bus destinations section of the WebSphere Application Server information center for further information.
  • A remote queue definition, replacing the local queue definition within WebSphere MQ, to cause messages sent to the destination queue to be forwarded over the WebSphere MQ link to the bus.
    Note this is just one possible option for configuring queue name resolution within the queue manager to forward messages over the link.
Summary
    This deployment option allows the message ordering capabilities of WebSphere MQ (which include when sending over a channel) to be combined with the additional messages ordering facilities provided by the default messaging provider for WebSphere Application Server (which prevent out of order delivery in transaction recovery scenarios).
    However, this deployment option is the most complex described in this technote. It requires planning, and runtime administration, of a bus topology in addition to a WebSphere MQ topology. It also adds internal complexity as messages are converted automatically between the low-level WebSphere MQ and default messaging provider formats as they travel over the WebSphere MQ link.
Circumstances in which messages might be delivered out of order
  • None expected
Considerations for clustered deployment
    Ordered delivery from the bus destination to the MDB is enforced automatically in a clustered environment when the "Strict message ordering" tickbox is checked for the destination.
    The main consideration for a clustered environment is establishing high availability of the WebSphere MQ link between the queue manager and the bus.
    See SupportPac MR01 for information about establishing a highly available link between a queue manager and a bus.

Rate this page:

(0 users)Average rating

Document information


More support for:

WebSphere Application Server
Java Message Service (JMS)

Software version:

6.0.2, 6.1, 7.0, 8.0, 8.5

Operating system(s):

AIX, HP-UX, IBM i, Linux, Solaris, Windows, i5/OS

Software edition:

Base, Network Deployment

Reference #:

1446463

Modified date:

2011-03-22

Translate my page

Machine Translation

Content navigation