[jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable: spurious Connection instances on concurrent connects
Richard Achmatowicz (JIRA)
jira-events at lists.jboss.org
Fri Jun 26 12:10:57 EDT 2009
[ https://jira.jboss.org/jira/browse/JGRP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473989#action_12473989 ]
Richard Achmatowicz commented on JGRP-549:
------------------------------------------
Looks as though the unit test ConnectionTableTest.testConcurrentConnect() which appears in HEAD:/tests/junit-functional was not pulled back to 2.4.
I'm adding the test to Branch_2_4 version of ConnectionTableTest.
It had to be adjusted slightly as the interface of CyclicBarrier changed from EDU.oswego.cs.dl.util.concurrent to java.util.concurrent.
> ConnectionTable: spurious Connection instances on concurrent connects
> ---------------------------------------------------------------------
>
> Key: JGRP-549
> URL: https://jira.jboss.org/jira/browse/JGRP-549
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 2.4.7, 2.6
>
>
> If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
> - A attempts to connect to B (new Socket())
> - B attempts to connect to A
> - A accepts B's connection and adds an entry for B into its table
> - B adds an entry for A into its table
> - B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
> - We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
> - Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
> GOAL:
> #1 Have only 1 TCP connection between any 2 members
> #2 Establish a handshaking mechanism, to avoid spurious connections
> SOLUTION:
> - When A establishes a connection to B, A needs to get agreement from B first (and vice versa)
--
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
More information about the jboss-jira
mailing list