[jboss-jira] [JBoss JIRA] Reopened: (JBAS-3262) Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology.

Analyze and adjust for impact of Multiplexer viewAccepted() semantics on services that monitor cluster topology. ---------------------------------------------------------------------------------------------------------------- Key: JBAS-3262 URL: http://jira.jboss.com/jira/browse/JBAS-3262 Project: JBoss Application Server Issue Type: Task Security Level: Public(Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Critical Original Estimate: 1 week Remaining Estimate: 1 week With the JGroups Mutliplexer, viewAccepted() notifications will not be sent out as services that create/destroy a MuxChannel connect and disconnect, but only when the mutliplexed JChannel connects and disconnects. JGroups MembershipListener implementations that are expecting a tighter relationship between a service lifecycle and viewAccepted() notifications may have trouble with this behavior. HAPartition implements MembershipListener, and then passes the view info on to any implementation of HAPartition.HAMembershipListener. Scanning in the AS codebase for implementations of that interface, I find: 1) DRM. I have to check more carefully, but I believe DRM will handle MUX semantics just fine. A major function of DRM is to maintain a registry of what higher level services are using the channel; those higher level services tell DRM when they come and go. For DRM viewAccepted() is more of a second line of defense in case of node crashes, etc. 2) org.jboss.aspects.versioned.DistributedSynchronizationManager. I'm not even sure exactly what this is, but it's using view changes to find and remove distributed locks held by the members no longer in the view. This could break if an app holding locks were redeployed but the channel was not. But, I think that problem exists regardless of whether MUX is involved. 3) TopologyMonitorService. OK w/ MUX semantics if the purpose of monitoring was to see who was using the multiplexed JChannel. Not OK if the purpose was to monitor who was using the HAPartition on top of the multiplexed JChannel. This is a distinction users of the service will probably find difficult to understand. Also, may miss the initial viewAccepted() if the HAPartition is deployed separately from the JChannel. 4) ClusterFileTransfer (part of farming). Uses viewAccepted to stop in-progress file transfers to/from dead nodes. Again, if a remote HAPartion is redeployed but the JChannel is not, this event will be missed.