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)