[infinispan-dev] Strict Expiration

[William Burns]

This is a necro of [1].

With Infinispan 8.0 we are adding in clustered expiration.  That includes
an expiration event raised that is clustered as well.  Unfortunately
expiration events currently occur multiple times (if numOwners > 1) at
different times across nodes in a cluster.  This makes coordinating a
single cluster expiration event quite difficult.

To work around this I am proposing that the expiration of an event is done
solely by the owner of the given key that is now expired.  This would fix
the issue of having multiple events and the event can be raised while
holding the lock for the given key so concurrent modifications would not be
an issue.

The problem arises when you have other nodes that have expiration set but
expire at different times.  Max idle is the biggest offender with this as a
read on an owner only refreshes the owners timestamp, meaning other owners
would not be updated and expire preemptively.  To have expiration work
properly in this case you would need coordination between the owners to see
if anyone has a higher value.  This requires blocking and would have to be
done while accessing a key that is expired to be sure if expiration
happened or not.

The linked dev listing proposed instead to only expire an entry by the
reaper thread and not on access.  In this case a read will return a non
null value until it is fully expired, increasing hit ratios possibly.

Their are quire a bit of real benefits for this:

1. Cluster cache reads would be much simpler and wouldn't have to block to
verify the object exists or not since this would only be done by the reaper
thread (note this would have only happened if the entry was expired
locally).  An access would just return the value immediately.
2. Each node only expires entries it owns in the reaper thread reducing how
many entries they must check or remove.  This also provides a single point
where events would be raised as we need.
3. A lot of code can now be removed and made simpler as it no longer has to
check for expiration.  The expiration check would only be done in 1 place,
the expiration reaper thread.

The main issue with this proposal is as the other listing mentions is if
user code expects the value to be gone after expiration for correctness.  I
would say this use case is not as compelling for maxIdle, especially since
we never supported it properly.  And in the case of lifespan the user could
very easily store the expiration time in the object that they can check
after a get as pointed out in the other thread.

[1]
http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-strictly-not-returning-expired-values-td3428763.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150713/b65a0e1c/attachment.html