JBAS-4228 Preferred master node for HASingleton

[alexfu.novell]

It seems that I only need to add a property to specify a "preferred" master node for a HASingletonElectionPolicy. However, there is no constructor from ClusterNodeImpl or IpAddress to take a single representation String, e.g.

inetaddress:port

I can use two properties though, it will look like:

<property name="preferredMasterInetaddres">127.0.0.1</property>
<property name="preferredMasterPort">1234</property>

Then people have to remember to set up both entries, which is not good.
Any thoughts/ideas?

Thanks!
-Alex

http://jira.jboss.com/jira/browse/JBAS-4228

[alexfu.novell]

OK. It seems that the implementation of ClusterNode.getName() has the following format:

ip:port

so I can add the following property

<property name="preferredMasterNode">ip:port</property>

and do the comparison

preferredMasterNode.equals(clusternode.getName())

Thanks,
-Alex

[brian.stansberry]

Alex,

Sorry for slow response; travelling last week.

The ip:port approach sounds fine.

[alexfu.novell]

The <property name="preferredMasterNode">ip:port</property> approach sounds fine.

Thanks Brian. I will check in the code as soon as passing the unit test.

-Alex

[galder.zamarreno]

This came out of a discussion with Brian:

HASingletonElectionPolicy should only contain methods that actually called from the HASingletonSupport/HASingletonController classes so that they can inject attributes to the election policy that users don't have to specify in the ha singleton election policy bean definition.Therefore,

/**
 * Sets the preferred master node. As long as the preferred master node
 * presents in the cluster, it will be always selected as master node,
 * no matter what the election policy is.
 * @param node String format of ip_address:port_number
 */
 void setPreferredMaster(String node);

 String getPreferredMaster();

methods should not live in HASingletonElectionPolicy, but instead in HASingletonElectionPolicySimple. They could be defined by HASingletonElectionPolicySimpleMBean and implemented by HASingletonElectionPolicySimple, depending whether it makes sense to be accessible and potentially modified at runtime.

Shall I reopen JBAS-4228 or create a new JIRA? If agreed, the change will happen for JBoss 5. What do we wanna do about 4.2? Leave it as it is?

[brian.stansberry]

This shouldn't be in HASingletonElectionPolicyBase or HASingletonElectionPolicySimple. It should be in its own policy impl class.

Go ahead an use a different JIRA since beta3 is out.

[galder.zamarreno]

http://jira.jboss.com/jira/browse/JBAS-5161

[brian.stansberry]

We're seeing some failures on hudson on the HASingletonElectionPolicyTestCase. I believe the issue is that preferred master is being set to 127.0.0.1:1099 but the hudson run is not binding node0 to localhost.

I'll fix this by making the preferred master ${node0.bind.address}:1099 and then modifying testsuite/imports/server-config.xml to pass node0.bind.address to both servers.

[brian.stansberry]

OK, that fix to the testsuite broke the test in a different way; e.g. if node0 = localhost. In that case preferredMaster=localhost:1099 but the ClusterNode.getName() returns 127.0.0.1:1099. Not a match.

I'm playing a bit with HASingletonElectionPolicyBase.elect() to try and parse out the InetAddress and port to allow matching on that if the name match fails.

[brian.stansberry]

I've implemented something along the above lines in HASingletonElectionPolicyBase. Basically checking for a symbolicname:1099 and converting to a dotteddecimal:1099 and seeing if that matches.

I put this in HASingletonElectionPolicyBase as that's where the rest currently is in trunk, but you'll need to move it to PreferredMasterElectionPolicy.

[galder.zamarreno]

OK, no probs. Thanks for the heads up.

Had a quick look at implementing JBAS-5161 the other day and there're a couple of things I wanted to mention:

1.- The intention of JBAS-4228, according to the JIRA, is that if a preferred master is there, use it, otherwise fall back on standard policy. The standard policy imo is the policy that should be applied when no election policies defined, which is, as per HASingletonSupport.partitionTopologyChanged(), :

isElectedNewMaster = isDRMMasterReplica();

So, I think we should have a default policy with this implemented and have PreferredMasterElectionPolicy extend it.

The current implementation has the preferred master code included HASingletonElectionPolicyBase and if not defined, defaults on the abstract implementation of elect(). So, in reality is doing, if preferred master not available, leave it the election policy defined (for example, in the tests HASingletonElectionPolicySimple).

Personally, I'm more inclined to implementing the default policy in HASingletonElectionPolicyBase and PMEP extending it. Thoughts?

2.- Does PreferredMasterElectionPolicy need an MBean interface? We had a chat about this stuff in a previous forum post. I don't think there's a need to have an MBean interface at this level. If anyone wants to check or change this at runtime, this could be done via HASingletonSupportMBean.set/getElectionPolicy() bearing in mind that HASingletonControllerMBean extends HASingletonSupportMBean. Thoughts?

[brian.stansberry]

1.- The intention of JBAS-4228, according to the JIRA, is that if a preferred master is there, use it, otherwise fall back on standard policy. The standard policy imo is the policy that should be applied when no election policies defined, which is, as per HASingletonSupport.partitionTopologyChanged(), :

isElectedNewMaster = isDRMMasterReplica();

So, I think we should have a default policy with this implemented and have PreferredMasterElectionPolicy extend it.

I want it to keep extending HASingletonElectionPolicySimple. That really is the new default, in the sense that a call to isDRMMasterReplica() is basically the same as a HASEPS with a default 0 position. Extending HASEPS lets us have the simple added feature of that class.

2.- Does PreferredMasterElectionPolicy need an MBean interface? We had a chat about this stuff in a previous forum post. I don't think there's a need to have an MBean interface at this level. If anyone wants to check or change this at runtime, this could be done via HASingletonSupportMBean.set/getElectionPolicy() bearing in mind that HASingletonControllerMBean extends HASingletonSupportMBean. Thoughts?

Yeah, give it an MBean interface. Let people change the preferred master via the JMX console. Changing a string attribute is a lot simple to support via tools vs. having to plug in a new polcy instance.

[galder.zamarreno]

I want it to keep extending HASingletonElectionPolicySimple. That really is the new default, in the sense that a call to isDRMMasterReplica() is basically the same as a HASEPS with a default 0 position. Extending HASEPS lets us have the simple added feature of that class.

Fair point.

Yeah, give it an MBean interface. Let people change the preferred master via the JMX console. Changing a string attribute is a lot simple to support via tools vs. having to plug in a new polcy instance.

Ok.

[galder.zamarreno]

I've got JBAS-5161 ready to be committed. There's a small change though that I wanted to pass through the forum before committing it:

Instead of parsing host:port manually by searching for colon and then calling substring, I thought it'll be easier and less cumbersome to parse it via an URI. To do this, I create a new URI from "cluster://" + preferredMaster, i.e.

/**
 * Create a URI instance from the given preferred master.
 *
 * @param str contains the String format of the preferred master.
 * @return an instance of URI, or null if the str cannot be parsed.
 */
 protected URI createUri(String str)
 {
 try
 {
 return new URI("cluster://" + preferredMaster);
 }
 catch (URISyntaxException use)
 {
 log.debug("Cannot extract URI from " + preferredMaster, use);
 }

 return null;
 }

and then call getHost() and getPort() on the URI instance to get the host/ip and port values.

Even though a new URI is inmutable, I haven't cached it cos preferred master can be changed at runtime. URI is just an identifier in comparison to URL, so I don't expect creation of URI instances to be costly.

To make sure I didn't introduce any bugs with this, I've also created PreferredMasterElectionPolicyUnitTestCase that contains several standalone tests that probe different inputs for preferred master.

Brian, I'll send you a patch before committing in case you wanna have a look to it.

[brian.stansberry]

OK, that's fine.

Re: testing, can you do a couple things:

1) Move the preferred master tests into a separate method from the simple ones. Just to make it easier to understand from looking at hudson what's being tested is if a test fails.

2) Make sure there's a test of preferred master where the specified master doesn't exist. Probably you should configure the ordinal to -1 or something so it picks the second node.