I'm answering your two latest posts here... Tim wrote : No need for the method to public - it will only be called from inside the post office I lefted it public for now only, it simplifies my tests... But I might keep it public for testcases purposes. Tim wrote : If the failover is driven from inside the postoffice then shouldn't need this on the interface? When the client fails, the client will send its original nodeID through createConsumer on ServerSessionDelegate, that method will need to create find Bindings on the PostOffice. It will need the nodeId to perform such operation. all the methods on PostOffice will have a method(nodeId...) equivalent now. I will revise maybe removing some of these methods if I don't need those. Tim wrote : Doesn't sound right to me. I'll have a look at the code. I will comment on that after I have debuged today. But I feel like we will need for certain scenarios. If the new server doesn't get for some reason a message on its references, it won't remove the reference from the database. I'm still investigating this. Tim wrote : There should be no need to check if the queue is clustered and not local, they will *always* be clustered and not local in the name map for a remote node, so this is redundant. A double check has to be done anyway IMO. I'm only replacing ClusteredQueues and if for any reason the queue was already replaced by a local queue, I will just ignore it. Tim wrote : The correct type is Binding, not DefaultBinding? Yep... already changed it. when I was typing this I *thought* DefaultBinding introduced extra properties I would need. Tim wrote : The remove needs to be broadcast across the cluster so other nodes can remove the binding too I will have to think about this. Other nodes on the cluster will still need a RemoteQueueStub point to the channelID on the failedOver node. Tim wrote : Isn't there going to be a problem creating two bindings with the same name? Not on DefaultRouter as I have changed it. I will check other data structures / make some tests. Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982126#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...