You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2015/07/14 23:23:05 UTC

[jira] [Commented] (GEODE-92) PR with entry eviction 1 leaves 3 entries in memory with async overflow

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

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

Commit dceac32e8ec60c3c7d32324cabd74f1ae5451fac 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=dceac32 ]

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. I've filed GEODE-92 and
GEODE-93 for the issues I've found with this new test.


> PR with entry eviction 1 leaves 3 entries in memory with async overflow
> -----------------------------------------------------------------------
>
>                 Key: GEODE-92
>                 URL: https://issues.apache.org/jira/browse/GEODE-92
>             Project: Geode
>          Issue Type: Bug
>            Reporter: Dan Smith
>         Attachments: 0001-Test-that-demonstrates-two-many-entries-in-memory-wi.patch
>
>
> I discovered this while working on a unit test for another issue. It appears that when configuring a PR with entry eviction 1, in some cases there ends up being more than 1 entry left in memory when using overflow to disk with disk-synchronous=false.
> With synchronous disk, this issue does not occur.



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