[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=12745303#comment-12745303 ] 

Bela Ban commented on JGRP-1549:
--------------------------------

I changed the code according to the above proposal, and added byteman based tests (see TCPConnectionMapTest) to enforce concurrent connections.
The test suite passes, but I want to do more testing before I merge my change to master.

This code will only live in 3.3, as there were quite a few changes, and I don't want to de-stabilize 3.2.x. After all, the existing code isn't incorrect, just inefficient.
                
> 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