[
https://jira.jboss.org/jira/browse/JBREM-1182?page=com.atlassian.jira.plu...
]
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