These tests need to work with the node0/node1 configuration elements. The exact values for these need not work because localhost tends to not work correctly for multicast on all platforms. In the qa env the testsuite node0/node1 are overriden to user local ip addresses. These tests are currently failing in the qa lab runs, so they do need to be fixed to work in that setting:
When I look at the qa test log, it doesn't appear that the ip addresses are being overridden in the qa environment. Node0 is being set to localhost and Node1 to a server named build01-01.pri. In my local environment, the use of localhost as one of the nodes seems to cause errors in the hajndi tests (more tests fail on my machine than in the qa environment). All hajndi tests run fine locally if I use actual IP addresses for the two nodes.
Right now, it looks like the new AutoDiscovery test is the only one that's failing in the QA environment. If it needs to work with Node0=localhost, I'll see whether I can find an alternative test that will exercise AutoDiscovery capabilities. Otherwise, I can remove it from the suite.
I'll ask Ryan how this is being run for the cruisecontrol tests.
Yes, the node0 is set to localhost in the (newer) cruisecontrol box. node1 is set to a private IP address as you indicate. I thought we had multicast routes setup correctly on this box, but perhaps I am wrong. How can I verify this?
We could setup a seperate private IP address for node0, but my preference would be to make the test work with localhost, since it is the default.
The problem doesn't seem to be in the test itself. When I set node0=localhost, the NamingContext class doesn't issue a request for AutoDiscovery. I'm not sufficiently familiar with NamingContext and AutomaticDiscovery to know whether it should work properly in this situation.
I'll modify the new HA-JNDI AutomaticDiscovery test so that it only runs if node0 is not localhost. This will allow testing AutoDiscovery in multiple IP address environments (presumably what most networks use) while not introducing a failing test to the testsuite. I'll emit a notification to the log when the test is circumvented in this manner.
Maybe someone else has more insight into this issue.
There are already auto discover tests for naming in the org.jboss.test.naming.test.SimpleUnitTestCase that do work with localhost, so how do these new tests differ? See:
I wasn't aware of those tests. I looked in the org.jboss.test.cluster subpackages for HA-JNDI and AutoDiscovery tests before I added HA-JNDI tests last year and the AutoDiscovery test last week. I'll take a look and see if the new AutoDiscovery test offers anything different.
I've reviewed the HA tests in SimpleUnitTestCase and in HAJndiTestCase. The basic difference is that SimpleUnitTestCase tests operate on a single node while the HAJndiTestCase tests utilize a cluster.
An example test in HAJndiTestCase would be to bind objects locally and via HA-JNDI on node0 and then try lookups from the HA server on node1.
In the case of the AutoDiscovery test, the local and ha bindings are on one node and the lookup is done using a context that has no provider url, forcing AutoDiscovery to be used.
I think the HAJndiTestCase tests are valid and should remain in the suite but I can see that the SimpleUnitTestCase is sufficient to ensure that AutoDiscovery is operational so the new AutoDiscovery test isn't essential.