[ https://issues.redhat.com/browse/ISPN-11176?page=com.atlassian.jira.plugi... ] Dan Berindei commented on ISPN-11176: ------------------------------------- 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}}. 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. 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 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)