[jboss-jira] [JBoss JIRA] Commented: (JGRP-549) ConnectionTable: spurious Connection instances on concurrent connects
[ http://jira.jboss.com/jira/browse/JGRP-549?page=comments#action_12368007 ]
Bela Ban commented on JGRP-549:
-------------------------------
A simple mechanism for agreement on concurrent send is (on A):
- Before actively establishing a connection (new Socket()) to B, we place an entry for B
into the conn table, the key is B, value is null
- On accept(B) (a passive connection establishment from B):
- If there is no key for B, we create a new Connection for B and add it to the conn
table
- Else:
- If B's address > A's address --> remove the existing entry for B and
add the newly created Connection for B
to the conn table
- Else close the incoming connection from B
We may still have to run getConnection() in a loop, random sleep after an unsuccessful
attempt to create a connection (but terminate if the host cannot be reached !).
This determinism ensures that only one of the 2 connection end points will get closed,
thus only 1 Connection will be created on concurrent send
ConnectionTable: spurious Connection instances on concurrent
connects
---------------------------------------------------------------------
Key: JGRP-549
URL: http://jira.jboss.com/jira/browse/JGRP-549
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira