[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

[galder.zamarreno@jboss.com]

Thanks for the link, that explains better the role of pickSingleton and isElectedMaster.

"bstansberry at jboss.com" wrote : Yes, makes sense to have the interface conform to what is actually used by external callers, with pickSingleton taking the newReplicants list.

Hmmm, do you wanna keep 

boolean isElectedMaster(List newReplicants);

or 

ClusterNode pickSingleton(List newReplicants);

or both?

In the thread link you mention, you mention:

"bstansberry at jboss.com" wrote : I like getting Address back instead of boolean -- that way the singleton knows who the master is. I'd keep a boolean version as well though, as a convenience, i.e. 
  | public boolean isElectedSingleton(List node) {
  | return pickSingleton(nodes).equals(partition.getLocalAddress());
  | }
  | 

HASingletonElectionPolicy should probably only select who should ran the singleton, that's its job, and HASingletonSupport can easily decide whether the singleton selected is the clustered node where HASingletonSupport code is running or not.

I'm not sure about the convenience of keeping the boolean version. By defining the boolean version in the interface as well, you are forcing people to implement it when you already know what the implementation will be. IOW, someone implementing this could provide a valid pickSingleton() implementation and an invalid implementation for isElectedMaster(). Sounds like a potential source for inconsistencies in implementations and double work vs avoiding an equals() call in HASingletonSupport.

"bstansberry at jboss.com" wrote : First, have a look at the original discussion on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=84307 to see if anything there triggers more thinking. From that, I think I see what happened. My original idea was the policy would have a ref to HAPartition and would know the target service name (i.e. what key the replicants are under in DRM). With that a call to a simple no-args isElectedMaster() method could allow the policy to access the DRM (via HAPartition) to get the current replicants. But I think the idea that the selection was based on the replicant list rather than the view got lost. 

I see. So, maybe we're creating more problems for ourselves by having those setHAPartition/getHAPartition and setManagedSingleton/getManagedSingleton? Getting the List might be all we need to actually decide the singleton to run in, unless there's information that is available through DRM and not through ClusterNode that could potentially be used to make such decision at some point.

WDYT?

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

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