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

"bstansberry@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.

"bstansberry@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());
}

"bstansberry@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.

"bstansberry@jboss.com" wrote:
My expectation here is any custom impl will be based off the base class, so we're handling the trivial stuff of storing the partition and singleton service refs. And if someone makes there own impl not using the base class and can't get that part right, well ....

"bstansberry@jboss.com" wrote:
Another thing to be aware of: the arg passed to HASingletonSupport.partitionTopologyChanged is really List<Object> newReplicants, where the list elements are *not* instances of ClusterNode. They are whatever "replicant" was registered for the service (i.e. an invoker stub, or in this case probably a String). There needs to be a translation into List<ClusterNode>. Looks like the way to do this is via DRM.lookupReplicantsNodeNames(String).

"bstansberry@jboss.com" wrote:
BTW, I downgraded this back to Major as the standard deploy-hasingleton in 4.2 is not using HASingletonElectionPolicy.

"bstansberry@jboss.com" wrote:
Crap. I see the following didn't make it into the interface:

/**
 * Called by the HASingleton to set the name with which the singleton
 * service is registered with the HAPartition.
 */
public void setServiceName(String serviceName);

public String getServiceName();

Those need to be there, otherwise an impl has no idea how to interact with the DRM.

/**
 * Called by the HASingleton to provide the election policy a reference to
 * itself. A policy that was designed to elect a particular kind of singleton
 * could downcast this object to a particular type and then access the
 * singleton for state information needed for the election decision.
 */
 void setManagedSingleton(Object singleton);

 Object getManagedSingleton();

I've switched to pickSingleton(List) and managed to get the singleton election tests running successfully again. A few notes/questions:

1.- I could do with having a method in DRM like this:

public List<ClusterNode> lookupReplicantsNodes(String key);

@Override
protected void startService() throws Exception
{
 if (mElectionPolicyMB != null)
 {
 mElectionPolicyMB.setHAPartition(getHAPartition());
 mElectionPolicyMB.setSingletonName(getServiceHAName());
 }

 super.startService();
}

@Override
protected void startService() throws Exception
{
 if (getElectionPolicy() != null)
 {
 getElectionPolicy.setSingletonObject(mSingleton);
 }

 super.startService();
}

Re 1) Done. http://jira.jboss.com/jira/browse/JBAS-5155

Re 2) Yeah, makes more sense. Generally you call super.start/create and then do your job, but had to put the election policy injections before super.startService which looked awkward to me. Putting in createService() override makes more sense

"bstansberry@jboss.com" wrote:
The fact that this will be done should be documented in HASingletonSupport(MBean).setElectionPolicy().

Re: http://jira.jboss.com/jira/browse/JBAS-5155

The other day was looking into the possibility of having this fixed in AS 4.x. There's 2 (well 4 really) ways this can be fixed:

1.- Add new API that allows either: a) passing the singleton name to the HASEP so that DRM can be queried, or b) passing a List to pickSingleton() with the ClusterNodes where the singleton is deployed.

2.- Use setManagedSingleton() as a way to pass the String version of the singleton name which is later used to query the DRM. It's got HACK written all over it, but we can do an instanceof for String within it in case someone out there calls this. One thing is for sure, a HASingleton can't be an instanceof String. This safes us the possibility of having to add new API in 4.x and all the trouble associated with it.

3.- Is it worth fixing this? Hmmmm, we haven't advertised this much which is good in some ways, but any day, someone running 4.x could come and report this to us in a support case.

4.- I guess we could take the add HA Singleton Election Policy functionality as experimental and hence not supported in 4.x. This could safe us a lot of headaches.

My preference right now is with either 2 or 4. Thoughts?

"smeng@unique" wrote:
Just to post my 2 cents on this matter, my company has some customers who really need HASingletonElectionPolicy functionality and are unlikely to upgrade to JBoss5 anytime soon. So we could really really do with this fix in AS 4.x

Sorry if I sound a bit aggressive but I'm just being anxious. Thank you for all your hard work.