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)
