"timfox" wrote : This is a good point, and one that I covered in the design WIKI page: http://wiki.jboss.org/wiki/Wiki.jsp?page=NewHADesignOverview (see the end of the page) | | Transferring queues back to a node if it recovers is a very difficult thing to do. Since consumers may be connected to the queues on the new node we can't just move them back to the old node. | | Theoretically this is possible by effectively failing them over again to the original node, however in this case any non persistent messages unacked in their sessions will get redelivered so this is not acceptable, if the sessions have any unacked np messages. | | This makes the whole thing complex, too complex to do initially. Eventually, if we decide to implement this it could also be used in the general case for the redistribution of connections across the cluster to best utilise available resources. But this is a nice to have and the pain to gain ratio is very high. I'm concerned on a scenario where a client reconnects back into serverA. A failed consumer will use the nodeID as part of the key of the subscriptionID (by either implementing subscriptionName containing nodeId or by changing PostOffice's signatures the way I have done). Let me explain of an example: I - Client connects into serverA II - Client creates durable subscriber (named subA) III - serverA fails IV - ServerB assumes subA V - Client decided to disconnect from server (session.close()) VI - ServerA comes back. VII - Client reconnects back (into serverA) VIII - Clients creates durable subscriber (named subA)... this won't give back the same channelID as nodeB would have the channel now. This could mean loss of messages. In a parallel scenario... I - Client connects into serverB II - Client creates durable subscriber (named subA (same name)) III - It won't use the same channelID as the one created from serverA as the original nodeId is different So... serverB will have two subscriptions... one from failed nodeA and another from nodeB. subscriptionA on serverB will be only accessible when serverA fails, and if the client reconnects back to serverA its queue won't be available there. One thing that I thought to solve this was transfering the queue back on serverA once serverA is back. If that's not possible maybe we could implement dependency between queues. Say.. the local queue would consume messages from the failed queue (with the same name) case the queue is empty. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982161#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...