You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Pavel Pereslegin (Jira)" <ji...@apache.org> on 2019/09/24 13:00:06 UTC
[jira] [Assigned] (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 ]
Pavel Pereslegin reassigned IGNITE-5302:
----------------------------------------
Assignee: (was: Pavel Pereslegin)
> 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
> Priority: Blocker
> Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.8
>
>
> 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
(v8.3.4#803005)