I'm not sure what you mean when you say "adding a general critical-heap-percentage parameter". The old xsd allowed it to be configured using xml. gfsh start server supports it with --critical-heap-percentage. And external java apis exist for it as John pointed out. Are you considering adding a gemfire property for it? That could be done. You would need to define which of them would take precedence if it is specified multiple ways but we already do that for other configurable attributes. Or do you mean something else by "parameter"? ________________________________ 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?
