[
https://issues.apache.org/jira/browse/IGNITE-20852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-20852:
---------------------------------------
Description:
Sometimes 2 nodes (A and B) try to establish logical connections to each other
at the same time. Only one of the connections can remain, so another one is
aborted. When such an abortion happens, the client that initiated the aborted
physical connection must be transparently switched to the connection opened
'from the other side'.
A subsituation where each of the competitors has already acquired a lock (at
different sides of the connection) is called a clinch. In other cases, one node
manages to take both locks.
In most of such situations, MessagingService gets an exception on one of the
sides. We must avoid this.
Another problem is that the clinch resulution protocol sometimes kills an
'almost established connection' (or even a fully estabished connection) [that
has managed to aquire recovery descriptors on both sides] just because another
connection (that has just failed to aquire first recovery descriptor) is
preferred by the tie-breaker. The tie-breaker must only be used in true clinch
situations (each of the competitors has 1 descriptor aquired).
was:
A clinch is a situation when two nodes (A and B) try to establish logical
connections to each other at the same time. Only one of the connections can
remain, so another one is aborted. When such an abortion happens, the client
that initiated the aborted physical connection must be transparently switched
to the connection opened 'from the other side'.
Instead, in most of the clinches, MessagingService gets an exception as a
result of the clinch resolution on one of the sides. We must avoid this.
Another problem is that the clinch resulution protocol sometimes kills an
'almost established connection' (or even a fully estabished connection) [that
has managed to aquire recovery descriptors on both sides] just because another
connection (that has just failed to aquire first recovery descriptor) is
preferred by the tie-breaker. The tie-breaker must only be used in true clinch
situations (each of the competitors have 1 descriptor aquired).
> Connection attempt clinches may cause connection failure
> --------------------------------------------------------
>
> Key: IGNITE-20852
> URL: https://issues.apache.org/jira/browse/IGNITE-20852
> Project: Ignite
> Issue Type: Bug
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes 2 nodes (A and B) try to establish logical connections to each
> other at the same time. Only one of the connections can remain, so another
> one is aborted. When such an abortion happens, the client that initiated the
> aborted physical connection must be transparently switched to the connection
> opened 'from the other side'.
> A subsituation where each of the competitors has already acquired a lock (at
> different sides of the connection) is called a clinch. In other cases, one
> node manages to take both locks.
> In most of such situations, MessagingService gets an exception on one of the
> sides. We must avoid this.
> Another problem is that the clinch resulution protocol sometimes kills an
> 'almost established connection' (or even a fully estabished connection) [that
> has managed to aquire recovery descriptors on both sides] just because
> another connection (that has just failed to aquire first recovery descriptor)
> is preferred by the tie-breaker. The tie-breaker must only be used in true
> clinch situations (each of the competitors has 1 descriptor aquired).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
