You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexey Goncharuk (JIRA)" <ji...@apache.org> on 2019/02/28 15:21:02 UTC

[jira] [Assigned] (IGNITE-11454) Race in ClientImpl may lead to client node segmentation on fast reconnect

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

Alexey Goncharuk reassigned IGNITE-11454:
-----------------------------------------

    Assignee: Alexey Goncharuk

> Race in ClientImpl may lead to client node segmentation on fast reconnect
> -------------------------------------------------------------------------
>
>                 Key: IGNITE-11454
>                 URL: https://issues.apache.org/jira/browse/IGNITE-11454
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Alexey Goncharuk
>            Assignee: Alexey Goncharuk
>            Priority: Major
>             Fix For: 2.8
>
>
> We have the following code in {{ClientImpl#tryJoin}}:
> {code}
>             if (spi.joinTimeout > 0) {
>                 final int joinCnt0 = joinCnt;
>                 timer.schedule(new TimerTask() {
>                     @Override public void run() {
>                         if (joinCnt == joinCnt0 && joining())
>                             queue.add(JOIN_TIMEOUT);
>                     }
>                 }, spi.joinTimeout);
>             }
> {code}
> We have a window when the timeout object is still scheduled, but the node is already connected to the cluster. The following sequence is possible: a node disconnects, clears it's queue, then timeout object is fired, adds a message to the queue, then {{tryJoin}} is called. In this case, the node will be immediately segmented.
> {{ClientReconnectAfterClusterRestartTest}} demonstrates this if join timeout is set to 10s.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)