[ https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-1549: ------------------------------------ I've written an Infinispan test that reproduces the problem pretty reliably (but with a pretty invasive modification in ClusterTopologyManagerImpl, delaying the rebalance confirmation). The sources are here: https://github.com/danberindei/infinispan/tree/t_jgrp-1549_m I tried to reproduce it with plain JGroups, but I wasn't successful. I think the initial discovery phase changed the way connections were created(the Infinispan test suite uses our custom TEST_PING protocol, so discovery doesn't create any connections). I've also looked at the code in TCPConnectionMap and I think I see two problems: 1. After creating a connection, a node should check the just-created connection against any existing connection in the map (only if it's open, obviously) and only replace it if it satisfies the same check that's in ConnectionAcceptor. 2. On a send exception, the sender should only close the connection that it used to send the message. The acceptor might have replaced the connection in the map sending was in progress. I think either one of these could explain why the initial message was dropped in the test. I'm not sure why UNICAST2:STABLE doesn't kick in and force the re-transmission of those messages for 15 seconds though... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1549: -------------------------------- A simple algorithm would work: - Before we connect to a dest (new Socket(), active creation) and it doesn't exist, we create a new dummy TCPConnection and add it to conns. The creator is also recorded in the TCPConnection - When the new Socket() call to dest returns successfully, we fill the contents of the TCPConnection *unless* (1) it was already already filled (e.g. by an accept(), see below) or (2) it is closed. In the latter case, we remove the TCPConnection - If an accept() is received, we check for *prevalence*: when comparing the sender's address with our own, then the higher address win. If we win, the incoming connection is closed and we don't replace the current TCPConnection. Else, we replace the current TCPConnection (and close the existing one). This scheme is similar to lock ordering in deadlock avoidance systems; it is always deterministic and the connection creator with the higher address always wins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira