"mohitanchlia" wrote : Such a great explanation. Why don't I get this from docs :) I know it takes so much keep up with the docs. http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Cl... is pretty close. :-) It lacks some of the implementation details of my post above; I'm currently redoing this guide for AS 5 so will think about adding that. Always a bit of a tradeoff; too much implementation detail and the concepts get lost, plus the implementation detail is changeable. And it's OSS, so the source is available. anonymous wrote : | So if I understand correctly, in above example if for some reason election policy choses Node D as master then the view will be {D,C} instead of {C,D}. Is there a way in JMX Console to see this kind of view. Who the master is does not affect the service view; it remains {C, D} even if the election policy says D is the master. Re: getting JMX Console info about the service view, you can access service view info via the jboss:service=DistributedReplicantManager,partitionName=DefaultPartition mbean. (Substitute your partition name for DefaultPartition if you configured something else, e.g. via the -g startup option). To use the mbean you need to know the name under which your service is registered. The "AllServices" mbean attribute lists them as a comma-delimited string. For an HASingletonController, by default it will be the the ObjectName of the controller mbean. Once you know the service name you can paste it as a param to the lookupReplicantsNodeNames() operation. The result will be the service view in string form. The DRM mbean also exposes a "isMasterReplica()" operation to which you pass the service name. Be cautious with this; it's a legacy operation from the days when the master was always the first node in the service view; all it does is tell you whether the current node is first in the service view. You can go to the mbean for your HASingletonController itself; it will tell you if it is the master. anonymous wrote : Also under the hoods does jgroup use NACKAK to do this kind of communication. Also are there different pings and FD to check Overall Cluster view and Service view. Service views are maintained at a higher level via DRM telling HAPartition to do group RPCs. HAPartition uses JGroups to do that RPC. NAKACK comes into play in the sense that it ensures all members of the cluster receive the RPC and that they receive it in the correct order. FD doesn't impact a service view directly, but it does have a big indirect impact, because a node can't be in a service view if it isn't also in the overall view. If JGroups suspects a node (e.g. due to not receiving FD heartbeat responses), the DRM gets a callback and that node is removed from all service views, and services interested in each service view get a callback telling them the service view changed. anonymous wrote : Thanks again for educating me. It's hard to work with clusters when you don't know what exactly is going on. Your best bet to understand in detail is to look at source code from http://anonsvn.jboss.org/repos/jbossas. Find the release you want under "tags"; most of the stuff relevant to this thread is in the "cluster" module under the root for the release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198103#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...