[jboss-jira] [JBoss JIRA] Commented: (JBAS-4422) org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host

[Richard Achmatowicz (JIRA)]

    [ 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