[jira] [Commented] (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:comment-tabpanel=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)
[jira] [Commented] (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:comment-tabpanel=16781560#comment-16781560
]
Ignite TC Bot commented on IGNITE-11454:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3203380buildTypeId=IgniteTests24Java8_RunAll]
> 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)
[jira] [Commented] (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:comment-tabpanel=16780624#comment-16780624
]
Alexey Goncharuk commented on IGNITE-11454:
---
Suggested solution is to check the join count in the message worker thread, so
that the race is never possible.
> 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)
