Aleksandar Kostadinov reopened EJBTHREE-880:
Perhaps the solution here is to be more careful in how we use the
"node0" ant property. If the set of tests requires localhost, the server should
be bound to "localhost" not to a variable "node0" and the test driver
should be told the server is bound to localhost, not "node0". This leaves node0
available as a variable for those test targets that need it.
+1 That's one thing I tried to suggest above.
> The whole purpose of having node0 and node1 is defeated btw. Why
use them when we still rely on localhost? Can't you use separate port sets to run your
No, it is not. We are talking about only EJB3 here, not the entire JBoss AS test suite.
So, node0 and node1 are still being used in other parts.
Yes, it does, because you can never know if these problematic tests will not run at the
> As well by multicasting, one is allowed to bind to specific
interfaces. So in case you really, really need to have everything on localhost (what I
still can't understand why), then by these tests you can specifically listen on lo and
send through lo.
If we have two interfaces, lo and eth0, with one JBoss instance in each, multi-casting
will still be affected by other JBoss instances accessible through eth0. In some tests, I
noticed that some external instances were able to join the cluster whose master was on
eth0, but lo was denied to join the cluster. So, even if they are on the same machine, lo
is not in the same group as eth0, causing failures.
Do you use the special MCAST_ADDR environment variable to specify a multicast group? Go
you use to change HA partition name for extra insurance? I'd guess not.
Anyways what I have suggested is for the tests, where node0 needs to be localhost, to
force mcast outgoing messages to 127.0.0.1 interface and listener join that mcast group on
the loopback interface as well. I believe there are jgroups properties for the matter. I
can see in
how to tell jgroups use a particular interface and not the default one. For more
properties see http://www.jboss.org/community/docs/DOC-12352
, I think you need the mping
mcast address as well. You could ask the jgroups guys as well.
As an example, there is a test which compares the hostname (localhost)
with the expected IP (127.0.0.1).
I wonder if this is something that really matters or just a random check put there long
ago. I've no idea what the test is trying to prove but I hope it is not java hostname
I suppose that customers have a network setup specially configured to
the clustering of their JBoss test instances, so they don't affect SIT/UAT/Production
instances. That's basically what I'm looking for here. Isolated environment, to
test everything related to EJB3 in a regular basis, without the need to take some
machine(s) down or manually configure on every run.
Well our lab setup was carefully prepared for JBoss AS test suite then jgroups, messaging
and cache were able to use the same. How does ejb3 has so specific needs not allowing it
to run in the same environment? Please try the suggested solutions listed above before
deciding it is unfixable.
Hard-coded localhost in ejb3 test suite
Project: EJB 3.0
Issue Type: Bug
Reporter: Aleksandar Kostadinov
Assignee: Juraci Paixao Krohling
Attachments: ejb3-4.0-testsuite Build Completed With Testsuite Errors.eml,
ejb3-4.2-testsuite Build Completed With Testsuite Errors.eml
When the ejb3 testsuite is run with "-Dnode0=IP1 -Dnode1=IP2" and
IP1!=localhost there are some tests failing with "Retries exceeded, couldn't
reconnect to 127.0.0.1:####". I see this for 4_0 and 4_2 jboss branches, but guess
it's the same with head.
One of the testcases is IiopRemoteUnitTestCase. I've checked
ejb3/src/test/org/jboss/ejb3/test/iiop/unit/IiopRemoteUnitTestCase.java and there is
"corbaloc::localhost:3528/NameService");'. Instead of localhost there should
be used the node0 property. I guess the others have the same problem.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira