[
https://issues.apache.org/jira/browse/GEODE-6304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756407#comment-16756407
]
ASF subversion and git services commented on GEODE-6304:
--------------------------------------------------------
Commit 546abdd173afe13c01e148900c2b9114dc5bc4cc in geode's branch
refs/heads/develop from Ryan McMahon
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=546abdd ]
GEODE-6304: Refactor memory monitor to properly reset tolerance counter (#3102)
The tolerance counter was not properly being reset between
non-consecutive EVICTION and CRITICAL events. To fix this and make it
more understandable, the threshold logic was combined with the logic to
compute the next state in the MemoryThreshold state machine. The
counter is now reset between non-consecutive EVICTION and CRITICAL
events.
> Heap memory monitor tolerance counter not properly reset
> --------------------------------------------------------
>
> Key: GEODE-6304
> URL: https://issues.apache.org/jira/browse/GEODE-6304
> Project: Geode
> Issue Type: Bug
> Components: configuration, eviction, regions
> Reporter: Ryan McMahon
> Assignee: Ryan McMahon
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The tolerance counter which determines whether a state change should actually
> be honored is not properly being reset when non-consecutive EVICTION or
> CRITICAL events are received. The purpose of this counter is to tolerate a
> configurable number of _consecutive_ "bad readings" of used bytes from the
> JVM, and was originally introduced for JRockit. However, it has been
> observed that bad readings are also possible in certain versions of Oracle
> JVM and possibly others.
> When the HeapMemoryMonitor was last refactored, a regression was introduced
> where the tolerance counter was not reset between non-consecutive EVICTION or
> CRITICAL events. This could cause an erroneous change of state if several
> non-consecutive events were received over some period of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
