[infinispan-issues] [JBoss JIRA] (ISPN-11176) XSite Max Idle

[Dan Berindei (Jira)]

    [ https://issues.redhat.com/browse/ISPN-11176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384408#comment-14384408 ] 

Dan Berindei commented on ISPN-11176:
-------------------------------------

> Entries will only expire when reaper is run, which can take a while if a store is present or the time is high

Thinking some more about this, we could also send the touch command on read, if the read happens later than {{last access + max-idle timeout - max-idle delay}}.
 Then we could expire the entries on read as well, we just need to do it later than {{last access + max-idle timeout}}.

> Entries that were read can still expire right after being read (even from same site). Option 2 would only expire an entry if the current site hasn't seen it, where as this could read from the same site and then have it expire.

Agree. But option 2 would also allow an entry to stay alive on one site after it has been removed on the other sites, and IMO that's worse.

> It adds another configuration option

Also true. I have thought about making it the 1x or 2x {{xsite backup timeout}}, but I didn't want to talk too much about the actual value.

> I don't think we can take away the fact that a local site read is sync to update max idle, because we would run into the original issue that required clustered xsite to be rewritten in that if a node goes down it can cause some entries to expire early.

I see it the other way around: IRAC already allows sites to make conflicting updates to the same key, and one of them wins so it's eventually consistent. So it's enough to make max-idle expiration eventually consistent as well, it's not worth adding the latency of a x-site RPC to make max-idle expiration as consistent as it is in a single cluster.

 

One more thing: In your option 1, I think the purge expired task needs to behave like a read and send a wait for a {{check last access}} response before actually expiring the entry. This will require some tuning WRT how many expirations can be ongoing at the same time. In my proposal the purge expired task just sends async commands, but it may need a limit as well, to avoid taking too much bandwidth/processing time away from real work.

> XSite Max Idle
> --------------
>
>                 Key: ISPN-11176
>                 URL: https://issues.redhat.com/browse/ISPN-11176
>             Project: Infinispan
>          Issue Type: Enhancement
>          Components: Cross-Site Replication, Expiration
>            Reporter: Will Burns
>            Assignee: Will Burns
>            Priority: Major
>             Fix For: 12.0.0.Final
>
>
> Max idle expiration currently doesn't work with xsite. That is if an entry was written and replicated to both sites but one site never reads the value, but the other does. If they then need to read the value from the other site it will be expired (assuming the max idle time has elapsed).
> There are a few ways we can do this.
> 1. Keep access times local to every site. When a site finds an entry is expired it asks the other site(s) if it has a more recent access. If a site is known to have gone down we should touch all entries, since they may not have updated access times. Requires very little additional xsite communication.
> 2. Batch touch commands and only send every so often. Has window of loss, but should be small. Requires more site usage. Wouldn't work for really low max idle times as an entry could expire before the touch command is replicated.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)