[jira] [Updated] (GEODE-9150) partition region expiration uses extra memory on secondaries

["Darrel Schneider (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-9150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darrel Schneider updated GEODE-9150:
------------------------------------
    Labels: GeodeOperationAPI  (was: )

> partition region expiration uses extra memory on secondaries
> ------------------------------------------------------------
>
>                 Key: GEODE-9150
>                 URL: https://issues.apache.org/jira/browse/GEODE-9150
>             Project: Geode
>          Issue Type: Improvement
>          Components: expiration
>            Reporter: Darrel Schneider
>            Priority: Major
>              Labels: GeodeOperationAPI
>
> Partition region expiration usually drives all the expiration from the primary (the unusual case is when the pr also has evict destroy in which case expiration is done on primary and secondaries). But the secondaries still have all the expiration tasks (one for each entry which consumes about 112 bytes of memory per entry). When they fire on the secondary the go into a different pendingExpiry map owned by each bucket. They hang around in that map until the primary expiration happens or a secondary becomes primary. The pendingExpiry map also eats up some memory.
> What we could do instead if no expiration scheduling on secondaries. When a secondary becomes primary that it could kick off a background thread scheduling an expiry task for each entry. Currently when it becomes primary it processes the pending expiry map so that could be replaced with scheduling expiry. LocalRegion already has the code that supports rescheduling expiry since it is something users can dynamically change on an existing region. This would not only reduce the memory usage on secondaries but also simplify our expiration implementation.  PR eviction currently complicates our pr expiration implementation but if our pr eviction destroy was always distributed when the region had expiration, then we would not need any special expiration code to deal with evict destroy.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)