[ https://issues.apache.org/jira/browse/IGNITE-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781629#comment-16781629 ]
Sergey Chugunov commented on IGNITE-11454: ------------------------------------------ [~agoncharuk], I didn't come up with scenarios where proposed patch could incorrectly segment node. So I think we are safe to merge it to master. > 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 > > Time Spent: 10m > Remaining Estimate: 0h > > 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)