Why is calling InternalResourceManager.setCriticalHeapPercentage(..) necessary?
This configuration setting is accessible from the public API GemFireCache.getResourceManager().setCriticalHeapPercentage(..). Perhaps this configuration property can be specific to the Geode Redis module?? For instance, SDG also exposes certain properties to configure API only settings, e.g. [1], or alternatively, [2]. -j [1] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/config/annotation/ClientCacheApplication.html#criticalHeapPercentage-- [2] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/config/annotation/PeerCacheApplication.html#criticalHeapPercentage-- ________________________________ From: Raymond Ingles <ring...@vmware.com> Sent: Friday, February 26, 2021 11:05 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Proposal: new Geode property CRITICAL_HEAP_PERCENTAGE The Geode Redis Compatibility code is working to emulate the Redis eviction policy “noevict”; when memory fills up, the server refuses new write commands until deletion or expiration has cleared space. Right now, part of the implementation is calling InternalResourceManager.setCritialHeapPercentage() to ensure that LowMemoryExceptions are thrown before heap memory actually runs out. It makes sense to make this configurable rather than hardcoding the specific percentage, obviously. Since this is a cache-wide setting (and probably useful to other components) we didn’t think it would necessarily be appropriate to add a redis-specific option (redis-critical-heap-percentage). What would the implications be to adding a general critical-heap-percentage parameter? Are there existing reasons that this hasn’t already been done? gfsh already supports these options when starting a member. Does anyone have a strong preference (or aversion) to one or the other?
