3 Replies Latest reply on Jan 8, 2009 12:28 AM by Yong Hao Gao

    JBMESSAGING-1457 - Unexistent destinations on both nodes

    Clebert Suconic Master

      Howard, I think you need to add a test somehow you have destinations deployed in only one node (without any messages), and failover with other destinations deployed on both nodes.

      You need to validate the test in two cases.

      - destinations only deployed in one node, but no messages on them.
      - destinations only deployed in one node, but with messages on them


      on both cases you need a second destination with messages on both nodes. The failover on that second destination shouldn't be affected.

        • 1. Re: JBMESSAGING-1457 - Unexistent destinations on both nodes
          Yong Hao Gao Master

          Yes, that make sense, I'll add the tests. Thanks Clebert.

          • 2. Re: JBMESSAGING-1457 - Unexistent destinations on both nodes
            Clebert Suconic Master

            Howard,


            I'm not sure if the current fix is correct.

            You should just ignore the Queue.. yes.. but on MessagingPostOfficeImpl::performFailover:

            }
             else
             {
             //Cannot failover if there is no queue deployed.
            
             log.warn("Cannot failover " + queue.getName() + " since it does not exist on this node. " +
             "You must deploy your clustered destinations on ALL nodes of the cluster");
             }
            


            I don't think deleteBindingFromStorage(queue) should be called. As merge didn't work because of the warning, we need to make sure the data will be received when the failed server restarts.


            //Delete from storage
            
             //Note we must do this *after* we have done any merge.
             //This is because if we did it first, then the merge failed, we'd be left with the old channel deleted
             //but the messages would have still be in the old channel
             //meaning they would have disappeared from the users point of view and it would involve manual
             //database intervention to correct it
             //See http://jira.jboss.com/jira/browse/JBMESSAGING-1113
            
             deleteBindingFromStorage(queue);
            
             log.debug(this + " deleted binding for " + queue.getName());
            
             // Note we do not need to send an unbind request across the cluster - this is because
             // when the node crashes a view change will hit the other nodes and that will cause
             // all binding data for that node to be removed anyway.
             }
            


            So, you should improve one of the tests to validate the failed queue still have data when everything is restarted, and move the deletebindingFromStorage to be called right after merge:

            if (localQueue != null)
             {
             //need to merge the queues
            
             log.debug(this + " has already a queue: " + queue.getName() + " queue so merging queues");
            
             localQueue.mergeIn(queue.getChannelID(), failedNodeID.intValue());
            
             log.debug("Merged queue");
            
             deleteBindingFromSTorage(queue); // something like that
             }