[ http://jira.jboss.com/jira/browse/JBMESSAGING-519?page=all ] Tim Fox updated JBMESSAGING-519: -------------------------------- Fix Version/s: 1.2.0.Alpha1 (was: 1.2.0.Beta1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-519?page=comments#action_12... ] Tim Fox commented on JBMESSAGING-519: ------------------------------------- This task can probably be split into two: 1) The client side management of failover. The maintenance of the client side list of servers, the client side load balancing policy. 2) The server side management of failover. This is how I think failover should work: On the server side, if a node fails, this needs to be detected by the group. The failover node for the node that failed needs to then take over responsibility for any queues that the failed node was handling - it effectively "becomes" that node. Any non persistent messages will be lost. Any persistent messsages will be loaded for those queues from the database. If in memory message persistence is being used then no need to load them from the db. Thing to consider: When the failed node comes back - how to handle the responsibility for the queues back to the original node? This probably isn't possible since new connections may have connected to the failover node and we can't just boot them off, or move them to the other node since they will lose non persistent messages. Note that we DO NOT need to replicate delivery state of sessions to the failover node. This will be too slow. Instead we can get transparent failover by the client "replaying" the session to the failed over server. On the client side, when the client detects server failure, it chooses a new server to try. This must match the failover server. Something to think about: How can we ensure that the client doesn't failover to the new server *before* the new server has failed over it's queues? The client starts a new JMS connection, then recreates automatically all the sessions it had on the pervious failed connection. For each session, the client then tells the server the ids of all the delivered but unacknowldged messages it had at point of failure. The server then recreates its delivery lisst from this information. The sessions can then continue as normal - with perhaps redelivery of any non persistent messages that were in the failed sessions. (persistent messages will be ok) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-519?page=all ] Clebert Suconic updated JBMESSAGING-519: ---------------------------------------- JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976347#... I have also created a WIKI that will contain the design on HA: http://wiki.jboss.org/wiki/Wiki.jsp?page=NewMessagingHADesign -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-519?page=comments#action_12... ] Clebert Suconic commented on JBMESSAGING-519: --------------------------------------------- Maybe we should create subtasks for clientFailoever: zero - Modeling metada I - MessageProducer failover II - MessageReceiver failover III - BrowserReceiver failoever IV - Server list (server side) V - Receiving ConnectionFail events VI - Resending acks on messages received before connectionFailed event -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBMESSAGING-519?page=all ] Tim Fox updated JBMESSAGING-519: -------------------------------- Description: Implement fully transparent failover for JMS clients and server side failover as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewHADesignOverview (was: Implement fully transparent failover for JMS clients as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira