[
https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin....
]
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)