JBossDeveloper

Re 1) Each of the different preferred master definitions is in a different test method, i.e. testIpPort, testHostPort, testOnlyPort, testNonNumericPort, testUnknownHost... that should be enough, shouldn't it?

Re 2) I think I have that one covered, i.e.

public void testUnknownHost() throws Exception
 {
 policy.setPreferredMaster("onceuponatimeinalandfarfaraway:1199");
 /* invalid preferred master definiton, so 1st candidate in the list
 * should be chosen */
 assertEquals(candidates.get(0), policy.elect());
 }

Btw, while running the the clustered tests for ha singleton election, I have spotted the following WARN message when the last node in the cluster stops and this is the node where the ha singleton was running:

2008-02-10 22:50:57,675 WARN [org.jboss.ha.singleton.HASingletonController] Stopping failed test:service=HASingletonController_1
java.lang.IllegalStateException: list of cluster node candidates where to run the singleton cannot be null
at org.jboss.ha.singleton.HASingletonElectionPolicyBase.elect(HASingletonElectionPolicyBase.java:103)
at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:169)
at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:244)

I'm gonna change HASingletonElectionPolicyBase so that it doesn't throw a ISE when the list of candidates, but instead logs a debug message.

I'll make HASingletonElectionPolicy.elect() return null on those occasions which requires noting it in the javadoc and a couple of extra lines in HASingletonSupport.partitionTopologyChanged():

boolean isElectedNewMaster;
if (mElectionPolicyMB != null)
{
 ClusterNode electedNode = mElectionPolicyMB.elect();
 isElectedNewMaster = electedNode != null ? electedNode.equals(getHAPartition().getClusterNode()) : false;
}
else
{
 isElectedNewMaster = isDRMMasterReplica();
}

I'm not looking at code right now, just using slightly tired memory of what I saw last week, so please bear with me...

Re 1) Each of the different preferred master definitions is in a different test method, i.e. testIpPort, testHostPort, testOnlyPort, testNonNumericPort, testUnknownHost... that should be enough, shouldn't it?

I was tallking about the old test method that's been there all along, where you'd added some assertions re: some beans you'd added that use preferred master. I was just wanted those assertions moved into a separate method, so that the original method was a test of HASingletonElectionPolicySimple and the other assertions were in a separate method. Just a minor thing.

Re 2) I think I have that one covered

OK, good. :-)

Btw, while running the the clustered tests for ha singleton election, I have spotted the following WARN message

Kudos to you for looking at the logs. Looking at testsuite logs for unexpected WARNs and ERRORs is an excellent way to find all sorts of random problems no one had thought about. Tedious and painful but very important to do from time to time.

Your solution sounds fine.

 

"bstansberry@jboss.com" wrote:
I'm not looking at code right now, just using slightly tired memory of what I saw last week, so please bear with me...

Re 1) Each of the different preferred master definitions is in a different test method, i.e. testIpPort, testHostPort, testOnlyPort, testNonNumericPort, testUnknownHost... that should be enough, shouldn't it?

I was tallking about the old test method that's been there all along, where you'd added some assertions re: some beans you'd added that use preferred master. I was just wanted those assertions moved into a separate method, so that the original method was a test of HASingletonElectionPolicySimple and the other assertions were in a separate method. Just a minor thing.

Apologies if my previous explanation was not precise enough. In fact, I've created a separate test class called PreferredMasterElectionPolicyUnitTestCase that contains these tests for two reasons:

1.- They're standalone unit tests, no need to have AS running for them.
2.- They're PreferredMasterElectionPolicy specific in the sense that I test any type of input into setPreferredMaster() and see whether it choses the given master after calling elect(). If the given master is invalid for any reason, it should delegate on the simple election policy.

"bstansberry@jboss.com" wrote:

Btw, while running the the clustered tests for ha singleton election, I have spotted the following WARN message

Kudos to you for looking at the logs. Looking at testsuite logs for unexpected WARNs and ERRORs is an excellent way to find all sorts of random problems no one had thought about. Tedious and painful but very important to do from time to time.

Your solution sounds fine.

Cheers :)))