anonymous wrote : | 1. ServerConnectionFactoryEndpoint sends a view update to ALL active connections returned by the ConnectionManager instance. Why does it send it to all? Didn't you mention that this has to be sent on a "filtered" list of connections? This JIRA issue (http://jira.jboss.com/jira/browse/JBMESSAGING-759 ) is about this. oops... fixing it... easy fix. We need a testcase that uses two connectionFactory though. anonymous wrote : 2. Why the code that sends the view update (currently hosted by ServerConnectionFactoryEndpoint) is not located at ConnectionManager level? Seems more appropriate to be there... | I was wondering if we should lock the factory while updating the clients or not. Since there is that possibility we would require a ReadWriteLock on the CFEndpoint. Since there is a possibility of locking the CF that was an indication for me the right place for the update would be the CFEndpoint itself. anonymous wrote : 3. Why do you keep a different "activeConnections" set at ConnectionManger level? Speed reasons? You got all the information you need in the "endpoints" map already. Keep in mind that cluster view update events are very rare events, considering the time scale at which messaging operates. Why would you need to optimize that, risking cache desynchronization? | The active connection list is on a three levels HashMap list VMId->ClientId->Connection. It seemed simpler to have a simple HashSet, managed by the very same routines. I can change that if you like. anonymous wrote : 4. What's the difference between a LoadBalancingPolicy and a LoadBalancingFactory? Why do you configure a ConnectionFactory service with the latter instead of the former? The LoadBalancingPolicy is not static any more.. you need a Policy per Connection created. This was working before because Serialization was creating new instances for you... and besides you had a comment about not making it static any more. anonymous wrote : 5. What is this: | Code: | | // FailoverNodeID is not on the map, that means the ConnectionFactory was updated | // by another connection in another server.. So we will have to guess the failoverID | // by numeric order. Case we guessed the new server wrongly we will have to rely on | // redirect from failover | | | | (ClusteringAspect.java line 211). | Why do we need to guess the failover ID? | Take a look on the 4th message at this thread (Posted: Mon Jan 15, 2007 17:35 PM) and some others after that. Case the Factory is updated before failover happens, there is a change the failoverID is not on the MAP any more. On that case we would require a random node to try a hopping. Instead of a random node I'm guessing the node... and if it fails hopping will take care of it. anonymous wrote : 6. ClusterViewUpdateTest.testUpdateConnectionFactory() fails. I executed the whole testsuite about two times between yesterday and today.. and didn't get any failures. Maybe you have a local problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003910#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...