Darrel Schneider created GEODE-1787: ---------------------------------------
Summary: when recovering persistent region whose configuration has changed the disk stats may end up wrong Key: GEODE-1787 URL: https://issues.apache.org/jira/browse/GEODE-1787 Project: Geode Issue Type: Bug Components: persistence Reporter: Darrel Schneider Code inspection shows a possible problem in AbstractRegionMap.copyRecoveredEntries. The code in this method that copies an entry from one map to another (this only happens when the region was persisted with one region configuration but then finds it is being recovered with a different one which usually does not happen). It looks like when this copy happens that we may end up incrementing the disk stats again causing entries to be counted twice. I could be wrong about this. A test case needs to be added that demonstrates the problem. Here is the comment in the code that make this spot: // TODO: passing value to createEntry causes a problem with the disk stats. // The disk stats have already been set to track oldRe. // So when we call createEntry we probably want to give it REMOVED_PHASE1 // and then set the value in copyRecoveredEntry it a way that does not // change the disk stats. This also depends on DiskEntry.Helper.initialize not changing the stats for REMOVED_PHASE1 If this is a problem then in can be worked around (and you will have better performance) by following the documented instructions on changing the persisted region configuration to match the configuration you will be using during recovery. It uses the gfsh alter off-line disk-store command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)