[ https://issues.apache.org/jira/browse/IGNITE-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Mashenkov reopened IGNITE-7832: -------------------------------------- > Ignite.resetLostPartitions() resets state under race. > ----------------------------------------------------- > > Key: IGNITE-7832 > URL: https://issues.apache.org/jira/browse/IGNITE-7832 > Project: Ignite > Issue Type: Task > Components: cache > Reporter: Andrew Mashenkov > Priority: Major > > Assume, we have event listener that detects partition loss events and apply > some actions to recover lost data. > After recovery process finished an Ignite.resetLostPartitions() method should > be called to mark all lost cache partitions as healthy. > It is possible Ignite.resetLostPartitions() will be called during exchange, > but right before a new partition loss event will be fired. > E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in > detectLostPartitions() method, while user thread will wait for the lock > inside Ignite.resetLostPartitions(). > So, after a new partition loss will be detected, is will be not possible to > abort user action and state of just lost partition will be reset. > For that case, we should either abort resetLostPartitions() or reset > partitions state regarding topology version provided by user some how. -- This message was sent by Atlassian JIRA (v7.6.3#76005)