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

Roman Puchkovskiy updated IGNITE-21336:
---------------------------------------
    Description: 
We have a connection recovery mechanism that transparently re-establishes a 
connection whose Channel was closed. This means that a sender should never see 
ClosedChannelException as a result of a send. There is a race now that allows a 
sender to get such an exception.

The same race might also cause a message to not be added to the unacknowledged 
messages queue, which might offset acknowledgement and put connection 
restoration logic at risk (some messages might not be resent).

Also, message ordering might be compromised due to the same race on the 
boundary between the old and new channels in the same logical connection.

  was:
We have a connection recovery mechanism that transparently re-establishes a 
connection whose Channel was closed. This means that a sender should never see 
ClosedChannelException as a result of a send. There is a race now that allows a 
sender to get such an exception.

A retry logic should be added (in DefaultMessagingService) to make sure this 
exception just caused a retry (leading to reestablishing the connection or 
failing to reestablish it).


> Handle ClosedChannelException gracefully
> ----------------------------------------
>
>                 Key: IGNITE-21336
>                 URL: https://issues.apache.org/jira/browse/IGNITE-21336
>             Project: Ignite
>          Issue Type: Improvement
>          Components: networking
>            Reporter: Roman Puchkovskiy
>            Assignee: Roman Puchkovskiy
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have a connection recovery mechanism that transparently re-establishes a 
> connection whose Channel was closed. This means that a sender should never 
> see ClosedChannelException as a result of a send. There is a race now that 
> allows a sender to get such an exception.
> The same race might also cause a message to not be added to the 
> unacknowledged messages queue, which might offset acknowledgement and put 
> connection restoration logic at risk (some messages might not be resent).
> Also, message ordering might be compromised due to the same race on the 
> boundary between the old and new channels in the same logical connection.



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

Reply via email to