[
https://issues.apache.org/jira/browse/GEODE-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9799:
------------------------------------
Priority: Minor (was: Major)
> javadocs describing PartitionRegion's local-max-memory misleading
> -----------------------------------------------------------------
>
> Key: GEODE-9799
> URL: https://issues.apache.org/jira/browse/GEODE-9799
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Darrel Schneider
> Priority: Minor
>
> The javadocs on for local-max-memory say: "the maximum amount of local memory
> that can be used by the Region". This is not true. The region can use more
> memory. The javadocs on PartitionAttributes.getLocalMaxMemory and
> PartitionAttributesFactory.setLocalMaxMemory should be improved. The geode
> docs do a better job of describing this feature. In most cases don't bother
> setting local-max-memory. In some rare cases you may want to set it to 0 so
> that certain server do not store any of the region's data. Here is the geode
> docs (I find it saying "set aside" confusing because Geode does not actually
> do that):
> bq. Maximum megabytes of memory set aside for this region in the local
> member. This is all memory used for this partitioned region - for primary
> buckets and any redundant copies. This value must be smaller than the Java
> settings for the initial or maximum JVM heap. When the memory use goes above
> this value, Geode issues a warning, but operation continues. Besides setting
> the maximum memory to use for the member, this setting also tells Geode how
> to balance the load between members where the region is defined. For example,
> if one member sets this value to twice the value of another member’s setting,
> Geode works to keep the ratio between the first and the second at two-to-one,
> regardless of how little memory the region consumes. This is a local
> parameter that applies only to the local member. A value of 0 disables local
> data caching.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)