I'm back :)
I've got this pretty much nailed down for 4.2.x. Here's a summary of what I've
done:
- created org.jboss.ha.singleton.ExtendedElectionPolicy (dropped verbose HASingleton from
class name) which contains setSingletonName()/getSingletonName() methods that would allow
a extended election policy to query DRM. The benefit of this is that it allows original
isElectedMaster() to still be called as it is, but the difference is in the impl (whether
extended or not), or more specifically, in the pickSingleton() impl.
- created paralel ExtendedElectionPolicyBase, ExtendedElectionPolicyMBean,
ExtendedElectionPolicySimple and ExtendedElectionPolicySimpleMBean to avoid touching any
of the existing election policy classes.
- HASingletonSupport overrides setupPartition() to be able to set HAPartition and
singleton name before first election vote.
- setting singleton name is done this way to be able to cope with both extended and non
extended interface:
try
| {
| server.invoke(((MBeanProxyInstance)mElectionPolicyMB).getMBeanProxyObjectName(),
"setSingletonName", new Object[] {getServiceHAName()}, new String[]
{"java.lang.String"});
| }
| catch(ReflectionException re)
| {
| log.debug("Selected election policy does not support setting singleton name,
skipping assignment.");
| }
Remember than in 4.x, we set the eviction policy via proxy:
<depends optional-attribute-name="ElectionPolicy"
|
proxy-type="attribute">jboss.examples:service=HASingletonMBeanExample-ExtendedElectionPolicySimple_1</depends>
That's pretty much it. There's a final question I wanted to post here for
discussion:
The current javadoc for
APIHASingletonElectionPolicy.pickSingleton()/HASingletonElectionPolicy.pickSingleton(HAPartition)
does not mention the possibility of pickSingleton() returning null. In fact,
isElectedMaster calls something like: pickSingleton().equals() so it's definitely not
ready to accept a null value out of it.
When the last node in the cluster is stopping, the existing pickSingleton() implementation
just choses itself, even though it's undeploying the ha singleton in the very last
node. Bottom line: it's stopping the last node but ends up starting the ha singleton
when it shouldn't really.
The extended implementation I've worked on can detect this and return null out of
pickSingleton(), leading to isElectedMaster returning false. In that situation the
HASingleton will not be started as singleton if the last node in the cluster is shutting
down.
The 2nd is IMO the correct behaivour but requires
HASingletonElectionPolicyBase.isElectedMaster() to be able to cope with a null value being
returned from pickSingleton(). If I do that, iow if I return null from pickSingleton(),
I'm effectively breaking the original API javadoc for pickSingleton() though.
The fact that the HASingleton is started during the stoppage of the last node in the
cluster might not be a big deal, but I suppose on what the HASingleton.startSingleton()
does...
Might not be very important at the moment, but all this could be relevant at some point
depending on the HASingleton implementations out there and the users' expectations in
such circumstances.
Thoughts?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144589#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...