[
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)
