[
https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520542#comment-16520542
]
Dmitriy Pavlov commented on IGNITE-7163:
----------------------------------------
[~dkarachentsev],
Retrigger did not help:
{noformat}
Cache 4 [ tests 2 ]
IgniteCacheTestSuite4: CacheStopAndDestroySelfTest.testNearClose (fail
rate 0,0%)
IgniteCacheTestSuite4: CacheStopAndDestroySelfTest.testNearCloseWithTry
(fail rate 0,0%)
{noformat}
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache4&branch_IgniteTests24Java8=pull%2F4088%2Fhead&tab=buildTypeStatusDiv
{noformat}
Client Nodes [ tests 4 ]
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectAtomicCache (fail rate 0,0%)
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectComputeApi (fail rate 0,0%)
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectStreamerApi (fail rate 0,0%)
IgniteClientNodesTestSuite:
IgniteClientReconnectFailoverTest.testReconnectTxCache (fail rate 0,0%)
{noformat}
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ClientNodes&branch_IgniteTests24Java8=pull%2F4088%2Fhead&tab=buildTypeStatusDiv
could you please double check these tests?
> Validate connection from a pre-previous node
> --------------------------------------------
>
> Key: IGNITE-7163
> URL: https://issues.apache.org/jira/browse/IGNITE-7163
> Project: Ignite
> Issue Type: Sub-task
> Components: general
> Affects Versions: 2.3
> Reporter: Alexandr Kuramshin
> Assignee: Dmitry Karachentsev
> Priority: Major
> Labels: discovery
> Fix For: 2.6
>
>
> If some pre-previous node connects to the local node with the previous node
> in the message's failed nodes collection additional steps should be done:
> # Connection with the previous node should be validated.
> # If a message from the previous node was not received a long time ago, the
> previous node should be considered as failed and the pre-previous node
> connection accepted.
> # If the previous node connection is alive then different scenarios possible
> ## Answer with a new result code causing the pre-previous node to try to
> reconnect to the previous node
> ## Break connection with the pre-previous node causing to continue the
> possible cluster split.
> ## Check connections with nodes after pre-previous node and delay decision by
> answering RES_WAIT to get more predictable split and stable topology.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
