[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

[ovidiu.feodorov@jboss.com]

Clebert,

I've just taken a look at your check in. Here are several questions:

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.

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...

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?

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?

5. What is this:
            // 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?

6. ClusterViewUpdateTest.testUpdateConnectionFactory() fails.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003637#4003637

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003637