2 Replies Latest reply on Jun 10, 2010 10:27 PM by gaohoward

    DefaultPreserveOrdering in Failover condition

    gaohoward
    gaohoward Jun 10, 2010 3:24 AM

      Hi guys,


      In JBoss Messaging, messages can be sucked over between nodes in a cluster. If user wants strict ordering, meaning the messages are received in the order they are sent, he can set "DefaultPreserveOrdering" attribute to "true". Once this is set, a message will only be sucked once. If a message is sucked to another node, it stays in that node forever. However in failover condition, this behavior may change.

       

      For example, a JBM cluster of two nodes, Node A and Node B. A clustered queue Q is deployed in the cluster. A message is sent to Q in node A, then it is sucked over to Q in node B. After that, node B crashes and failover happens. The sucked message will be merged back to Q in nodeA. That effectively breaks the behavior.

       

      I don't know how to proper handle such a situation. Please give some opinion. Thanks.

      • 4067 Views
      • Tags:
        • 1. Re: DefaultPreserveOrdering in Failover condition
          gaohoward
          gaohoward Jun 10, 2010 3:54 AM (in response to gaohoward)

          One way to do is prevent the sucked messages from being merged over to the failover node. That makes those messages stuck in the failed node. Unless the failed node restart and have consumers, the message will never get consumed.

            • Actions
          • 2. Re: DefaultPreserveOrdering in Failover condition
            gaohoward
            gaohoward Jun 10, 2010 10:27 PM (in response to gaohoward)

            On second thought, "ordering in failure condition" is actually a feature not required by JMS spec? JBM has ordering group doing this. But this specific case, which requires "ordering in cluster under failure", is NOT supported by ordering group, which only support non-clustered (or ha-singleton) queues.

             

            So users who ask for this feature should turn to HornetQ.

             

            Comments?

             

            Howard

              • Actions