geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-498) Callback argument size is not reflected in bucket size for parallel queues
Date Mon, 26 Oct 2015 23:05:27 GMT

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

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

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

GEODE-244 Flush entries to disk in testRecoverRedundancyParallelAsyncEventQueue

The queue is configured for async persistence, which means entries were
being flushed to disk asynchronously. Due to GEODE-498, the size of the
buckets could vary widely if the entries were not flushed to disk,
causing the rebalance to have problems later.


> Callback argument size is not reflected in bucket size for parallel queues
> --------------------------------------------------------------------------
>
>                 Key: GEODE-498
>                 URL: https://issues.apache.org/jira/browse/GEODE-498
>             Project: Geode
>          Issue Type: Bug
>            Reporter: Dan Smith
>            Assignee: Darrel Schneider
>
> I found this while tracking down GEODE-244.  This appears to be a new problem that was
introduced by the off heap changes. This is problematic because this size is used for rebalancing
calculations, so bugs in the reported size could cause rebalancing issues.
> The issue is that the size reported by BucketRegion.getTotalBytes() is incorrect for
parallel async event queues. The size does not include the size of the callback argument.
> I tracked this down to this code in BucketRegion.calcMemSize, which looks like it was
added for offheap:
> {code}
> static int calcMemSize(Object value) {
>     if (value != null && (value instanceof GatewaySenderEventImpl)) {
>       return ((GatewaySenderEventImpl)value).getSerializedValueSize();
>     }
> ...
> }
> {code}
> Interestingly, it looks like for the purposes of eviction, we do include the callback
argument size, because the MemLRUCapacityController calls GatewaySenderEventImpl.getSizeInBytes



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

Mime
View raw message