[infinispan-issues] [JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

[William Burns (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554125#comment-13554125 ] 

William Burns edited comment on ISPN-9003 at 3/30/18 1:57 PM:
--------------------------------------------------------------

Talking with [~NadirX] we believe the best approach may be a consensus based removal of maxIdle entries. That is it will do the following things

1. Read occurs on node where maxIdle is expired and sends request to primary owner (blocks the read)
2. Primary owner locks the key
3. Primary sends message to all nodes asking if entry is expired due to maxIdle -(also updates the updated time on all keys - just in case it isn't expired)-
4. Primary receives responses to decide if it is expired
5a. Primary responds to read node and tells them if it was expired
5b. Primary removes from all nodes if it was expired
6. Cluster wide expiration occurs if necessary allowing for listeners to be invoked (including cluster listeners - which we didn't do before)

The above approach gives no overhead for reads when the entry is not present and is not expired. The only overhead is if a node finds that the entry was expired via maxIdle and then must block to confirm if it should be removed. However the chance of this occurring seems a bit low depending on what maxIdle was set to. If the expiration reaper finds the expired entry first it will properly update its timestamps or remove as needed.

Another side effect of this is that maxIdle may be refreshed for all entries that are transferred via state transfer since I don't think the access time is currently replicated when state transfer occurs.


was (Author: william.burns):
Talking with [~NadirX] we believe the best approach may be a consensus based removal of maxIdle entries. That is it will do the following things

1. Read occurs on node where maxIdle is expired and sends request to primary owner (blocks the read)
2. Primary owner locks the key
3. Primary sends message to all nodes asking if entry is expired due to maxIdle (also updates the updated time on all keys - just in case it isn't expired)
4. Primary receives responses to decide if it is expired
5a. Primary responds to read node and tells them if it was expired
5b. Primary removes from all nodes if it was expired
6. Cluster wide expiration occurs if necessary allowing for listeners to be invoked (including cluster listeners - which we didn't do before)

The above approach gives no overhead for reads when the entry is not present and is not expired. The only overhead is if a node finds that the entry was expired via maxIdle and then must block to confirm if it should be removed. However the chance of this occurring seems a bit low depending on what maxIdle was set to. If the expiration reaper finds the expired entry first it will properly update its timestamps or remove as needed.

Another side effect of this is that maxIdle may be refreshed for all entries that are transferred via state transfer since I don't think the access time is currently replicated when state transfer occurs.

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