[infinispan-issues] [JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration
Dan Berindei (JIRA)
issues at jboss.org
Mon Apr 2 07:01:00 EDT 2018
[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554593#comment-13554593 ]
Dan Berindei edited comment on ISPN-9003 at 4/2/18 7:00 AM:
------------------------------------------------------------
[~william.burns] I assume we also need a timer task on the primary as well, to handle scenarios like web session keys that are almost never accessed after expiration?
If we do have a timer task running on the primary, it would be running steps 2-6 for each entry that would be expired based on the local last-access timestamp. Then maybe reads should only check expiration on the primary as well, and the backups would just assume that the last-access timestamp on the primary is newer. (Come to think of it, I'm not sure why we didn't do the same for lifespan expiration.)
Then the timer task would need the primary owner to update its last-access timestamp with the latest timestamp from the backups. That means we need to send wall-clock timestamps across nodes, and we'll probably need tests with divergent clocks.
I think state transfer also updates the last-access timestamp, so we need to make sure that state transfer doesn't revive expired entries (accounting for different clocks and long delays applying state).
was (Author: dan.berindei):
@wburns I assume we also need a timer task on the primary as well, to handle scenarios like web session keys that are almost never accessed after expiration?
If we do have a timer task running on the primary, it would be running steps 2-6 for each entry that would be expired based on the local last-access timestamp. Then maybe reads should only check expiration on the primary as well, and the backups would just assume that the last-access timestamp on the primary is newer. (Come to think of it, I'm not sure why we didn't do the same for lifespan expiration.)
Then the timer task would need the primary owner to update its last-access timestamp with the latest timestamp from the backups. That means we need to send wall-clock timestamps across nodes, and we'll probably need tests with divergent clocks.
I think state transfer also updates the last-access timestamp, so we need to make sure that state transfer doesn't revive expired entries (accounting for different clocks and long delays applying state).
> Clustered maxIdle expiration
> ----------------------------
>
> Key: ISPN-9003
> URL: https://issues.jboss.org/browse/ISPN-9003
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: William Burns
> Fix For: 9.3.0.Beta1, 9.3.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
More information about the infinispan-issues
mailing list