[ 
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)

Reply via email to