[ 
https://issues.apache.org/jira/browse/IGNITE-20852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-20852:
---------------------------------------
    Description: 
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 case connection failure
> -------------------------------------------------------
>
>                 Key: IGNITE-20852
>                 URL: https://issues.apache.org/jira/browse/IGNITE-20852
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Roman Puchkovskiy
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>
> 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).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to