Tim wrote : ...why you think you need a ClusteredConnectionFactory... - How would you as an user, decide if you want to use an HAConnection or not? - The ClientConnectinFactory which is dealing with HA, is being called ClusteredClientConnectionFactory, and it aggregates ClientConnectinFactory[]. I will round robbing between the array of child factories. Tim wrote : ...and why you need to replicate more than the locatorURI? ClientConnectionFactory has also an equivalent ServerConnectionFactoryEndpoint, right? Looking at properties from ClientConnectionFactoryDelegate: | //... from superClass DelegateSupport: | protected int id; | | //... from the class itself | | protected String serverLocatorURI; | protected Version serverVersion; | protected int serverID; | protected boolean clientPing; | I would need to replicate at least the LocatorURI and the serverID and DelegateSupport::id, assuming serverVersion and clientPing won't never change. Well... as I had to store almost everything, why not to take this into a real instance of ClientConnectionFactoryDelegate? It made much more sense for me. Anyway... today I'm going to change ClusteredConnectionFactoryClient a lot today. I had created two classes: One ClusteredClientConnectionFactoryDelegateServer and another ClusteredConnectionFactoryClient. The server version was supposed to use serialization replaceObject with the Client version updating the list of server from one PostOffice. This didn't work of course.. I will change the PostOffice to re-register the ClusteredConnectionFactory when the View changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986862#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...