[
https://issues.jboss.org/browse/JGRP-1549?page=com.atlassian.jira.plugin....
]
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/...
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