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

Bela Ban (JIRA) jira-events at lists.jboss.org
Sat Jan 12 06:19:22 EST 2013


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

Bela Ban edited comment on JGRP-1549 at 1/12/13 6:18 AM:
---------------------------------------------------------

If a connection exists, but is currently closed, we'll retry *once* to get the connection again. This could be the creation of a new connection, or grabbing an existing connection which was added in the meantime by accept(). This works as connections to non-existing destinations will throw an exception and therefore the code path is different. In other words, we don't run this code when the dest doesn't exist (quite a frequent case, e.g. TCPPING listing non existing destinations).
Also, when closing a connection we make sure that we close *our* connection only, to avoid closing a new connection created and added to the connections after our connection was closed.
The tetsts are testConcurrentConnect{2} in https://github.com/belaban/JGroups/blob/master/tests/byteman/org/jgroups/tests/byteman/TCPConnectionMapTest.java

                
      was (Author: belaban):
    If a connection exists, but is currently closed, we'll retry *once* to get the connection again. This could be the creation of a new connection, or grabbing an existing connection which was added in the meantime by accept(). This works as connections to non-existing destinations will throw an exception and therefore the code path is different. In other words, we don't run this code when the dest doesn't exist (quite a frequent case, e.g. TCPPING listing non existing destinations).
Also, when closing a connection we make sure that we close *our* connection only, to avoid closing a new connection created and added to the connections after our connection was closed.

                  
> 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


More information about the jboss-jira mailing list