[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-1182) Update testsuite to run under Hudson

[Richard Achmatowicz (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBREM-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12507358#action_12507358 ] 

Richard Achmatowicz commented on JBREM-1182:
--------------------------------------------

2. Configuring JRunit to use the loopback interface

Sometimes, we don't have a network available and need to conduct testing locally. In such cases, we use the loopback interface.

When jrunit.bind_addr is the loopback address 127.0.0.1, this means that the TestDriver, TestClient and TestServer will be bound to the loopback interface (lo on Linux). 

On Linux, there is no default routing for multicast packets which involves the loopback interface lo. This means that if we have two JGroups processes which communicate via the interface lo, multicast packets for these proceses will be sent out onto eth0 and will not arrive on the loopback interface. Members will not see each other. We need to do something additional when working with JRunit processes which use the loopback interfcace. 

The usual solution is to add in a route for multicast which involves lo. In order for multicast packets to be able to be passed from two processes using lo, we need to (again on Linux) add in the route:
# route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
This has the effect of routing all multicast packets through the interface lo.  You need to remember to delete this route after use, as it drives all multicast traffic down lo.

Adding a new route on shared machines is not such a hot idea - so when running the testsuite say on Hudson, we shouldn't use the above approach. 
There is another way to achieve the same goal: instead of using routing to direct multicast packets onto lo, we can ask JGroups to send any multicast packets onto lo, in addition to another other interfaces it is sending them to (i.e. the jrunit.bind_addr interface).

In JGroups 2.2.9 and above, we can define the properties:
receive_on_all_interfaces=<true | false>
receive_interfaces=<list of interfaces> 
send_on_all_interfaces=<true | false>
send_interfaces=<list of interfaces>

which allow controlling which interfaces JGroups would use for sending unicast and multicast packets, and which interfaces used for receiving unicast and multicast packets. So, instead of defining a new route for multicast onto lo, we can use the parameters:

jrunit.receive_on_all_interfaces=true
jrunit.send_interfaces=127.0.0.1

Assuming we use jrunit.bind_addr=127.0.0.1, this will cause JGroups to 
(i) listen for multicast and unicast on both 192.168.0.100 (say, for eth0) as well as 127.0.0.1
(ii) send all unicast and multicast packets onto the interface 127.0.0.1

So, we get JGroups style connectivity with no additional route.





> Update testsuite to run under Hudson  
> --------------------------------------
>
>                 Key: JBREM-1182
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1182
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: general
>    Affects Versions: 2.2.3.SP1
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.2.3.SP2
>
>         Attachments: JBREM-1182.patch, jgroups.jar
>
>
> Update the JBoss Remoting testsuite to run under Hudson. Some current problems include:
> (i) on Linux, JRunit based tests are failing due to members not finding each other
> (ii) on Linux, under JDK6, JRunit based tests are not able to create a JGroups stack
> (iii) JRunit system properties specified by the user on the command line are not being passed the the JUnit targets correctly, and so have no effect on the tests
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira