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

[ https://jira.jboss.org/jira/browse/JBREM-1182?page=com.atlassian.jira.plu... ] Richard Achmatowicz commented on JBREM-1182: -------------------------------------------- I have now found out why JRunit was not working with the settings: -Djrunit.bind_addr=127.0.0.1 -Djrunit.mcast_addr=228.15.2.3 -Djrunit.mcast_port=45565 -Djrunit.receive_on_all_interfaces=false -Djrunit.send_on_all_interfaces=false -Djrunit.send_interfaces=127.0.0.1 At the level of TestDriver communicating with the two ServerTestHarness instances, the JGroups groups were forming correctly, but the ServerTestHarness processes were not receiving the RunTestMessage multicast by TestDriver after it gets confirmation of Server startup. I couldn't understand how some messages were getting through and others were not. Eventually, I realised that this was the first message that TestDriver multicasts on the specified send interface, 127.0.0.1. The problem arises in JGroups: look at this section of output from UDP.createSockets: jrunit using bind_address: 127.0.0.1 jrunit using mcast_addr: 228.15.2.3 jrunit using mcast_port: 45566 jrunit using receive_on_all_interfaces=false jrunit using send_on_all_interfaces=false jrunit using send_interfaces=127.0.0.1 props: UDP(mcast_addr=228.15.2.3;mcast_port=45566;bind_addr=127.0.0.1;tos=8;ucast_recv_buf_size=80000;ucast_send_buf_size=150000;mcast_send_buf_size=150000;mcast_recv_buf_size=80000;loopback=false;discard_incompatible_packets=true;max_bundle_size=64000;max_bundle_timeout=30;use_incoming_packet_handler=true;use_outgoing_packet_handler=false;ip_ttl=2;down_thread=false;up_thread=false;enable_bundling=false;receive_on_all_interfaces=false;send_on_all_interfaces=false;send_interfaces=127.0.0.1;):PING(timeout=2000;num_initial_members=3;up_thread=false;down_thread=false):MERGE2(min_interval=10000;max_interval=20000;up_thread=false;down_thread=false):FD_SOCK(up_thread=false;down_thread=false):FD(timeout=10000;max_tries=5;shun=true;up_thread=false;down_thread=false):VERIFY_SUSPECT(timeout=1500;up_thread=false;down_thread=false):pbcast.NAKACK(max_xmit_size=8192;use_mcast_xmit=false;gc_lag=0;retransmit_timeout=300,600,1200,2400,4800;up_thread=false;down_thread=false):UNICAST(timeout=300,600,1200,2400;up_thread=false;down_thread=false):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=50000;max_bytes=400000;up_thread=false;down_thread=false):VIEW_SYNC(avg_send_interval=60000;up_thread=false;down_thread=false):pbcast.GMS(join_timeout=3000;join_retry_timeout=2000;shun=false;view_bundling=false;print_local_addr=true;up_thread=false;down_thread=false):FC(max_credits=2000000;min_threshold=0.10;up_thread=false;down_thread=false):FRAG2(frag_size=60000;down_thread=false;up_thread=false):pbcast.STATE_TRANSFER(up_thread=false;down_thread=false) HELLO! local_addr=127.0.0.1:57464, mcast_addr=228.15.2.3:45566, bind_addr=/127.0.0.1, ttl=2 sock: bound to 127.0.0.1:57464, receive buffer size=55808, send buffer size=55808 mcast_recv_sock: bound to 127.0.0.1:45566, send buffer size=55808, receive buffer size=55808 1 mcast send sockets: 0:0:0:0:0:0:0:1%1:36720, send buffer size=55808, receive buffer size=55808 ------------------------------------------------------- GMS: address is 127.0.0.1:57464 ------------------------------------------------------- Note the mcast send socket used: it's an IPv6 version of localhost and not an IPv4 version, as specified in the system property -Djrunit.send_interfaces. It turns out that, if you don't start the MessageBus() with -Djava.net.preferIPv4Stack=true, this situation can arise, due to the way JGroups creates its multicast send sockets and the way NetworkInterface.getHostName() works when there is more than one IP address associated woith an interface (in this case, 127.0.0.1 and ::1). So, JGroups was sending multicasts on lo, but it was using an IPv6 stack and not an IPv4 stack. So the multicast receive in ServerTestHarness (whose processes by the way are started with -Djava.net.preferIPv4Stack=true) using his IPv4 stack would not receive the messages. The problem is fixed by adding a <sysprop name="java.net.preferIPv4Stack" value="true"/> to all of the junit targets which start test cases. -- 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