[
http://jira.jboss.com/jira/browse/JBAS-4422?page=comments#action_12372396 ]
Richard Achmatowicz commented on JBAS-4422:
-------------------------------------------
2. What is more interesting is explaining why TwiddleUnitTestCase, with the -s still
commented out, was passing on RHEL and HPUX, but failing on Windows and Solaris. This was
the state of affairs in AS 4.2 RC7.
In that case, the AS testsuite was started using the parameters:
-u to specify an alternate multicast address (instead of the default 230.0.0.4)
-node0 to specify the binding to a local IP address (insterad of the default localhost)
The TwiddleUnitTestCase, without the -s option, would in the first instance try to connect
to JNDI using localhost:1099. Because no AS was bound to that host/port, the connection
would fail. Then, JNDI
autodiscovery would send out a multicast message on 230.0.0.4:1102 to see if any AS
instances were listening on that address. Because the testsuite was started with the -u
option, the AS instance running as part of the testsuite would be listening for multiucast
messages on a multicast address other than 230.0.0.4, but on the same port 1102. On
Windows and Solaris, in order for a multicast message to be correctly received, both the
address and the port on the message must match the address and the port which the receiver
is listening on.
Thus, in the case of Windows (and Solaris), the mulicast messages were not received by the
AS instance started by the testsuite, auto-discovery failed, and the TwiddleUnitTestCase
could not succeed in obtaining an MBeanServerConnection to any AS instance, and so the
test failed.
On the other hand, when the same test was run on RHEL and HPUX, the same sequence of
events occurred, up to the point at which autodiscovery was initiated. But due to the
"bug" in RHEL and HPUX, for a multicast message to be received by a receiver,
only the multicast message port and the multicast receiver port need match, despite any
differences in multicast address (contact Brian Stansberry for more details!). The
multicast message was thus received, the AS instance offered itself as a JNDI server, the
MBeanServerConnection was retrieved by the TwiddleUnitTestCase, and the test passed.
That is my understanding of why the test passed on RHEL and HPUX, but failed on Solaris
and Windows.
org.jboss.test.util.test.TwiddleUnitTestCase can't connect to
host
------------------------------------------------------------------
Key: JBAS-4422
URL:
http://jira.jboss.com/jira/browse/JBAS-4422
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.2.0.CR2
Environment: x86, Windows 2003 , Sun and BEA JVM
Reporter: Richard Achmatowicz
Assigned To: Stan Silvert
Priority: Trivial
1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle
command line, execs the command line and checks that the output received from the server
macthes the expected output. Comamnd lines are built, based on OS type: there is one for
Windows and one for UNIX.
The command line built when executing on Windows is:
> cmd /C twiddle get "jboss.system:type=Server" "Started"
and the response should be
"Started=true"
It appears that twiddle had an option for specifying the server host, but this option has
been commented out.
When executing the test on Windows, twiddle tries by default to connect to the server
using localhost:1099.
2. When the testsuite is run using the parameters node0/node1 to specify the host IP
addresses, localhost:1099 is not available
and the test fails.
(please see the linked issue JBPAPP-176 for more details)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira