[ https://jira.jboss.org/jira/browse/JGRP-1087?page=com.atlassian.jira.plug... ] Richard Achmatowicz commented on JGRP-1087: ------------------------------------------- Testing for the release usually involves the following set of tests: (i) run the unit/functional tests (unittests-xml) (ii) run the non-unit tests against udp (all-tests-udp) (iii) run the non-unit tests against tcp (all-tests-tcp) (iv) run the manual tests These tests are usually run against IPv4 non-loopback addresses. However, this time, I will run the tests against a) IPv4 loopback addresses b) IPv4 non-loopback addresses c) IPv6 loopback addresses d) IPv6 non-loopback, global addresses The configs used are as follows: // IPv4 loopback // set a route for loopback of multicast messages: route add -net 224.0.0.0 netmask 240.0.0.0 dev lo jgroups.bind_addr=127.0.0.1 jgroups.tcpping.initial_hosts=127.0.0.1[7800] jgroups.udp.mcast_addr=232.15.15.15 jgroups.udp.mcast_port=45588 jgroups.udp.ip_ttl=5 jgroups.tunnel.router_host=127.0.0.1 jgroups.tunnel.router_port=12001 # use true for IPv6 and false for IPv4 jgroups.useIPv6=false // IPv4 non-loopback jgroups.bind_addr=192.168.2.12 jgroups.tcpping.initial_hosts=192.168.2.12[7800] jgroups.udp.mcast_addr=232.15.15.15 jgroups.udp.mcast_port=45588 jgroups.udp.ip_ttl=5 jgroups.tunnel.router_host=192.168.2.12 jgroups.tunnel.router_port=12001 # use true for IPv6 and false for IPv4 jgroups.useIPv6=false // IPv6 loopback // set a route for loopback of multicast messages: route -A inet6 add ff00::1/8 dev lo jgroups.bind_addr=::1 jgroups.tcpping.initial_hosts=::1[7800] jgroups.udp.mcast_addr=ff01::1 jgroups.udp.mcast_port=45588 jgroups.udp.ip_ttl=5 jgroups.tunnel.router_host=::1 jgroups.tunnel.router_port=12001 # use true for IPv6 and false for IPv4 jgroups.useIPv6=true // IPv6 non-loopback jgroups.bind_addr=3ffe:ffff:0100:f101::1 jgroups.tcpping.initial_hosts=3ffe:ffff:0100:f101::1[7800] jgroups.udp.mcast_addr=ff0e::1:2:3 jgroups.udp.mcast_port=45588 jgroups.udp.ip_ttl=5 jgroups.tunnel.router_host=3ffe:ffff:0100:f101::1 jgroups.tunnel.router_port=12001 # use true for IPv6 and false for IPv4 jgroups.useIPv6=true -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1087?page=com.atlassian.jira.plug... ] Richard Achmatowicz updated JGRP-1087: -------------------------------------- Description: This release is required for the EAP 4.2 and 4.3 CP releases, and is primarily a bug fix release. The release notes show the following bugs and tasks completed for this release: Release Notes - JGroups - Version 2.4.7 ** Bug * [JGRP-549] - ConnectionTable: spurious Connection instances on concurrent connects * [JGRP-956] - Binding to mcast address in UDP.java is not working on Linux with IPv6 * [JGRP-967] - Deadlock in FD_SOCK * [JGRP-981] - Wrong view with concurrent startup * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration * [JGRP-990] - Grammatical Error in log message: I'm being am suspected. * [JGRP-1000] - COMPRESS corrupts some messages * [JGRP-1060] - NAKACK has inconsistent internal state after concurrent node startup ** Task * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX was: This release is required for the EAP 4.2 and 4.3 CP releases. The release notes show the following bugs and tasks completed for this release: Release Notes - JGroups - Version 2.4.7 ** Bug * [JGRP-549] - ConnectionTable: spurious Connection instances on concurrent connects * [JGRP-956] - Binding to mcast address in UDP.java is not working on Linux with IPv6 * [JGRP-967] - Deadlock in FD_SOCK * [JGRP-981] - Wrong view with concurrent startup * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration * [JGRP-990] - Grammatical Error in log message: I'm being am suspected. * [JGRP-1000] - COMPRESS corrupts some messages * [JGRP-1060] - NAKACK has inconsistent internal state after concurrent node startup ** Task * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1087?page=com.atlassian.jira.plug... ] Richard Achmatowicz commented on JGRP-1087: ------------------------------------------- There is a problem with ConnectionTableTest on Fedora. When ports are allocated and then freed, as in the ports used for the connection table acceptor threads, they don't seem to become immediately available once freed. Thus, tests following the first test can't grab those same ports. This we have to allow a port range so that a free port can be chosen. But the clients in ConnectionTableTest use fixed port specifications, and so are not aware of any ranging which had to go on to find an available port. Seems that the test should be modified so that clirents are able to obtain the actual port obtained by the ConnectionTable. -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1087?page=com.atlassian.jira.plug... ] Richard Achmatowicz commented on JGRP-1087: ------------------------------------------- I wrote a small program which allocated sockets, closed them and the reallocated them on the same port, 10 times in a row. There is no problem doing this on Fedora. So the problem had to be somewhere in the JGroups code. One problem was that the following was being called: ct1 = new ConnectionTable(...) ; ct1.start() ; ... ct2 = new ConnectionTableNIO(..., false) ; ct2.start() ; Ports were not available because in the case of ConnectionTable, start() is called within the constructor, so that we were effectively calling it a second time. So removing the call to ct1.start() fixed that problem. On the other hand, for ConnectionTableNIO, because we pass a parameter false at the end of the signature, it means that start() is not called within the constructoir. So that particular invocation has to stay. Even with these changes, we were still seewing the above exception when running the test testStopConnection(). I put in a very small 100 ms delay between each test, and thats eems to fix the problem. This probably needs further investigation to see why my test program works fine and always can reuse its port, whereas ConnectionTable seemingly cannot. -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1087?page=com.atlassian.jira.plug... ] Richard Achmatowicz commented on JGRP-1087: ------------------------------------------- Test failures for loopback IPv6: ---------------------------------- org.jgroups.tests.ConcurrentStartupTest org.jgroups.tests.ConnectStressTest(udp).testConcurrentLeaves -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1087?page=com.atlassian.jira.plug... ] Richard Achmatowicz commented on JGRP-1087: ------------------------------------------- Ran through some manual tests (org.jgroups.Draw ) using two local laptops and IPv6 addresses to verify connectivity over IPv6 and TCPPING parsing. For example, running two instances of Draw oin a single host using TCP: $ java -Djava.net.preferIPv4Stack=false -Djgroups.bind_addr=::1 -Djgroups.tcpping.initial_hosts="::1[7800],::1[7801]" org.jgroups.demos.Draw -props tcp.xml Nov 3, 2009 8:31:19 PM org.jgroups.JChannel init INFO: JGroups version: 2.4.7.GA Nov 3, 2009 8:31:19 PM org.jgroups.protocols.FRAG2 setProperties INFO: frag_size=60000, overhead=200, new frag_size=59800 Nov 3, 2009 8:31:19 PM org.jgroups.protocols.FRAG2 up INFO: received CONFIG event: {bind_addr=/0:0:0:0:0:0:0:1} Nov 3, 2009 8:31:19 PM org.jgroups.blocks.ConnectionTable start INFO: server socket created on 0:0:0:0:0:0:0:1:7801 --------------------------------------------------------- GMS: address is 0:0:0:0:0:0:0:1:7801 (cluster=DrawGroupDemo) --------------------------------------------------------- Nov 3, 2009 8:31:19 PM org.jgroups.blocks.ConnectionTable getConnection INFO: created socket to 0:0:0:0:0:0:0:1:7800 ** View=[0:0:0:0:0:0:0:1:7800|1] [0:0:0:0:0:0:0:1:7800, 0:0:0:0:0:0:0:1:7801] $ java -Djava.net.preferIPv4Stack=false -Djgroups.bind_addr=::1 -Djgroups.tcpping.initial_hosts="::1[7800],::1[7801]" org.jgroups.demos.Draw -props tcp.xmlLocking assertion failure. Backtrace: Nov 3, 2009 8:30:27 PM org.jgroups.JChannel init INFO: JGroups version: 2.4.7.GA Nov 3, 2009 8:30:28 PM org.jgroups.protocols.FRAG2 setProperties INFO: frag_size=60000, overhead=200, new frag_size=59800 Nov 3, 2009 8:30:28 PM org.jgroups.protocols.FRAG2 up INFO: received CONFIG event: {bind_addr=/0:0:0:0:0:0:0:1} Nov 3, 2009 8:30:28 PM org.jgroups.blocks.ConnectionTable start INFO: server socket created on 0:0:0:0:0:0:0:1:7800 --------------------------------------------------------- GMS: address is 0:0:0:0:0:0:0:1:7800 (cluster=DrawGroupDemo) --------------------------------------------------------- ** View=[0:0:0:0:0:0:0:1:7800|0] [0:0:0:0:0:0:0:1:7800] ** View=[0:0:0:0:0:0:0:1:7800|1] [0:0:0:0:0:0:0:1:7800, 0:0:0:0:0:0:0:1:7801] Similarly, runing Draw across a network using two hosts (one host's view): $ java -Djava.net.preferIPv4Stack=false -Djgroups.bind_addr=3ffe:ffff:0100:f101::1 -Djgroups.tcpping.initial_hosts="3ffe:ffff:0100:f101::1[7800],3ffe:ffff:0100:f101::2[7800]" -Djgroups.udp.mcast_addr=ff0e::1:2:3 org.jgroups.demos.Draw -props tcp.xml Nov 3, 2009 8:52:07 PM org.jgroups.JChannel init INFO: JGroups version: 2.4.7.GA Nov 3, 2009 8:52:07 PM org.jgroups.protocols.FRAG2 setProperties INFO: frag_size=60000, overhead=200, new frag_size=59800 Nov 3, 2009 8:52:07 PM org.jgroups.protocols.FRAG2 up INFO: received CONFIG event: {bind_addr=/3ffe:ffff:100:f101:0:0:0:1} Nov 3, 2009 8:52:07 PM org.jgroups.blocks.ConnectionTable start INFO: server socket created on 3ffe:ffff:100:f101:0:0:0:1:7800 --------------------------------------------------------- GMS: address is 3ffe:ffff:100:f101:0:0:0:1:7800 (cluster=DrawGroupDemo) --------------------------------------------------------- Nov 3, 2009 8:52:07 PM org.jgroups.blocks.ConnectionTable getConnection INFO: created socket to 3ffe:ffff:100:f101:0:0:0:2:7800 ** View=[3ffe:ffff:100:f101:0:0:0:2:7800|5] [3ffe:ffff:100:f101:0:0:0:2:7800, 3ffe:ffff:100:f101:0:0:0:1:7800] ** View=[3ffe:ffff:100:f101:0:0:0:2:7800|6] [3ffe:ffff:100:f101:0:0:0:1:7800] Nov 3, 2009 8:52:17 PM org.jgroups.blocks.ConnectionTable getConnection INFO: created socket to 3ffe:ffff:100:f101:0:0:0:2:7800 Nov 3, 2009 8:52:40 PM org.jgroups.blocks.ConnectionTable run INFO: exception is java.net.SocketException: Socket closed -- 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

[ https://jira.jboss.org/jira/browse/JGRP-1087?page=com.atlassian.jira.plug... ] Richard Achmatowicz commented on JGRP-1087: ------------------------------------------- Uploaded release to source forge. Updated branches wiki. Uploaded release to maven2 repo. -- 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