You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Sergey Chugunov (JIRA)" <ji...@apache.org> on 2017/05/26 14:07:04 UTC

[jira] [Updated] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

     [ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Chugunov updated IGNITE-5302:
------------------------------------
    Description: 
h2. Notes
Test *testPartitionLossAndRecover* reproducing the issue can be found in ignite-5267 branch with PDS functionality.

h2. Steps to reproduce
# Four nodes are started, some key is added to partitioned cache
# Primary and backup nodes for the key are stopped, key's partition is declared LOST on remaining nodes
# Primary and backup nodes are started again, cache's lost partitions are reset
# Key is requested from cache

h2. Expected behavior
Correct value is returned from primary for this partition

h2. Actual behavior
Request for value is sent to node where partition is empty (not to primary node), null is returned

h2. Latest findings
# The main problem with the scenario is that request for key gets mapped not only to P/B nodes with real value but also to the node where that partition existed only in LOST state after P/B shutdown on step #2
# It was found that on step #3 after primary and backup are joined partition counter is increased for empty partition in LOST state which looks wrong

  was:
h2 Notes
Test *testPartitionLossAndRecover* reproducing the issue can be found in ignite-5267 branch with PDS functionality.

h2 Steps to reproduce
# Four nodes are started, some key is added to partitioned cache
# Primary and backup nodes for the key are stopped, key's partition is declared LOST on remaining nodes
# Primary and backup nodes are started again, cache's lost partitions are reset
# Key is requested from cache

h2 Expected behavior
Correct value is returned from primary for this partition

h2 Actual behavior
Request for value is sent to node where partition is empty (not to primary node), null is returned

h2 Latest findings
# The main problem with the scenario is that request for key gets mapped not only to P/B nodes with real value but also to the node where that partition existed only in LOST state after P/B shutdown on step #2
# It was found that on step #3 after primary and backup are joined partition counter is increased for empty partition in LOST state which looks wrong


> Empty LOST partition may be used as OWNING after resetting lost partitions
> --------------------------------------------------------------------------
>
>                 Key: IGNITE-5302
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5302
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Sergey Chugunov
>
> h2. Notes
> Test *testPartitionLossAndRecover* reproducing the issue can be found in ignite-5267 branch with PDS functionality.
> h2. Steps to reproduce
> # Four nodes are started, some key is added to partitioned cache
> # Primary and backup nodes for the key are stopped, key's partition is declared LOST on remaining nodes
> # Primary and backup nodes are started again, cache's lost partitions are reset
> # Key is requested from cache
> h2. Expected behavior
> Correct value is returned from primary for this partition
> h2. Actual behavior
> Request for value is sent to node where partition is empty (not to primary node), null is returned
> h2. Latest findings
> # The main problem with the scenario is that request for key gets mapped not only to P/B nodes with real value but also to the node where that partition existed only in LOST state after P/B shutdown on step #2
> # It was found that on step #3 after primary and backup are joined partition counter is increased for empty partition in LOST state which looks wrong



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)