[jira] [Commented] (GEODE-56) Put to partitioned region with overflow doesn't properly update numOverflowBytesOnDisk

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623149#comment-14623149 ] 

ASF subversion and git services commented on GEODE-56:
------------------------------------------------------

Commit 9dff599b9d1e0c04fed60e54a765ad2ef84e77d8 in incubator-geode's branch refs/heads/feature/GEODE-56 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=9dff599 ]

GEODE-56 Decrementing bytesOverflowedOnDisk when an update happens to an evicted entry.

For persistent regions, we were correctly updating this stat. But for
non persistent regions we did not read the old size on disk, so we were
not updating the stat.

If the entry was in the async queue, we only increment the stat once
when the final value is actually written to disk. So we will only
decrement the stat if the oldValue is not pending asynchronous write to
disk.

I'm still seeing issues with the entryCount. I've tracked this down to
what I think is a problem with tombstones. It appears when we modify an
entry that is a tombstone, we increment the entry count once for the new
value, and once for removing the tombstone. But I'm not sure if that is
the full story.


> Put to partitioned region with overflow doesn't properly update numOverflowBytesOnDisk
> --------------------------------------------------------------------------------------
>
>                 Key: GEODE-56
>                 URL: https://issues.apache.org/jira/browse/GEODE-56
>             Project: Geode
>          Issue Type: Bug
>          Components: core
>            Reporter: Dan Smith
>            Assignee: Dan Smith
>
> For the purposes of rebalancing, geode keeps track of the amount of data stored on disk in a counter - BucketRegion.numOverflowBytesOnDisk. 
> For regions that have overflow but not persistence, a put that replaces a value that was overflowed on disk does not correctly decrement the counter of bytes overflowed to disk.
> The issue is that that size of the entry on disk is read in an if block testing to see if the region is persistent (dr.isBackup())
> {code}
>           if (dr.isBackup()) {
>             dr.testIsRecoveredAndClear(did); // fixes bug 41409
>             oldValueLength = getValueLength(did);
> {code}
> Later it is used to change the stat, but it oldValueLength may not be set
> {code}
>               incrementBucketStats(region, 1/*InVM*/, -1/*OnDisk*/, -oldValueLength);
> {code}
> The net effect of this issue is that if a lot of puts happen to entries that are overflowed to disk, the size of the bucket will be inflated. This may then cause issues with rebalancing calculations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)