[jira] [Commented] (GEODE-3764) idle expiration will happen even if the entry has been accessed on a replicate

["Swapnil Bawaskar (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194164#comment-16194164 ] 

Swapnil Bawaskar commented on GEODE-3764:
-----------------------------------------

From the [eviction docs|https://gemfire.docs.pivotal.io/geode/developing/expiration/how_expiration_works.html] We have the same problem for PARTITION regions too: 
Expiration in partitioned regions is executed in the primary copy, based on the primary’s last accessed and last updated statistics.
Entry updates are always done in the primary copy, resetting the primary copy’s last updated and last accessed statistics.
Entry retrieval uses the most convenient available copy of the data, which may be one of the secondary copies. This provides the best performance at the cost of possibly not updating the primary copy’s statistic for last accessed time.
When the primary expires entries, it does not request last accessed statistics from the secondaries, as the performance hit would be too great. It expires entries based solely on the last time the entries were accessed in the primary copy.

When we fix the behavior for REPLICATE regions, we should fix it for PARTITION regions too.

> idle expiration will happen even if the entry has been accessed on a replicate
> ------------------------------------------------------------------------------
>
>                 Key: GEODE-3764
>                 URL: https://issues.apache.org/jira/browse/GEODE-3764
>             Project: Geode
>          Issue Type: Bug
>          Components: expiration
>            Reporter: Darrel Schneider
>
> Because idle expiration is currently always based on if the entry has been accessed on the local node it is possible that entries will idle expire even if they were accessed recently.
> Since reads are only sent to one member, the last access time is only updated on that member. The expiration action itself is distributed so if any member was not read from recently, it will cause the entry to be expired on the entire cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)