Strict message ordering using activation specifications or ASF listener ports connected to WebSphere MQ Version 6.0

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.

对于 WebSphere® Application Server V7 和更高版本,已稳定侦听器端口。有关更多信息,请参阅有关固定功能的文章。您应进行规划,以便将 WebSphere MQ 消息驱动的 Bean 部署配置由使用侦听器端口迁移为使用激活规范。[AIX Solaris HP-UX Linux Windows][IBM i]有关如何为非 ASF 方式配置激活规范的更多信息,请参阅为非 ASF 方式配置激活规范但是,仅当您确定此应用程序不必在版本低于 WebSphere Application Server V7 的应用程序服务器上工作时,您才能开始此迁移。例如,如果应用程序服务器集群中某些成员的版本为 V6.1,而某些成员为更高版本,那么仅当您将该集群中的所有应用程序服务器都迁移到此更高版本之后,才能迁移该集群上的应用程序以使用激活规范。

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 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

  • 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.
    • 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.
    Note: 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.

Circumstances in which messages can arrive out of order

Messages can arrive out of order with this deployment in the following circumstances:
  • 在事务恢复期间,可能会不按顺序传送消息:
    Note: 必须按特定顺序发生一组特定事件才能遇到这种情况,这是很少见的。然而,如果有序消息传送对于应用程序的运行很重要,那么您必须考虑这种情况。
    • 在从下列其中一个组件的故障中进行恢复期间,使用此部署选项可能会发生无序消息传送:
      • 主管 MDB 的应用程序服务器
      • WebSphere MQ 队列管理器
      • 连接应用程序服务器和队列管理器的网络
    • 如果其中一个组件在 MDB 事务的两阶段落实期间发生故障,那么应用程序服务器事务管理器将重新建立与队列管理器的连接,以在该组件再次可用时落实该事务。
    • 此恢复过程是一个异步过程,因此有可能在完成事务恢复过程之前就会开始将新消息传送到 MDB。如果事务恢复的结果是要回滚事务,那么该消息将返回到 WebSphere MQ 队列并重新传送到应用程序,此过程有可能在已传送新消息之后进行。
  • 在回滚事务之后,在重新传送已回滚的消息之前,可能会传送队列中的下一个可用消息:
    • 对于 ASF 侦听器端口,如果将最大重试次数设置为 0,那么在进行回滚时将停止该侦听器端口,从而会阻止在回滚后进行无序传送。但然后必须手动重新启动该侦听器端口。
    • 对于激活规范,如果选择在消息传送失败时停止端点并将暂挂端点之前的连续传送失败次数设置为 0,那么在进行回滚时将暂停消息端点,从而会阻止在回滚后进行无序传送。但然后必须手动恢复 MDB 的消息端点。有关更多信息,请参阅 WebSphere MQ 信息中心。
  • 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.

指示主题类型的图标 概念主题



时间戳记图标 最近一次更新时间: July 9, 2016 9:27
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmm_wmq_smo_mq6
文件名:cmm_wmq_smo_mq6.html