[jboss-jira] [JBoss JIRA] (JGRP-1549) TCP: handle concurrent connections more gracefully

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739653#comment-12739653 ] 

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.
                
> TCP: handle concurrent connections more gracefully
> --------------------------------------------------
>
>                 Key: JGRP-1549
>                 URL: https://issues.jboss.org/browse/JGRP-1549
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.3
>
>         Attachments: cft.log.gz
>
>
> When A connects to B and B connects to A *concurrently*, and no existing connections are present, then one member (with the higher address) will prevail, and the other one will close its connection and drop the message.
> This is not usually an issue, as higher-up layers will retransmit the message, thus re-establishing the connection.
> However, if we have a protocol based on negative acks, such as UNICAST2, the retransmission might take a while if that message was the last one.
> SOLUTION:
> The end that closes the connection should simply resend the message *once*, thus re-creating the connection.

--
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