[infinispan-dev] strictly not returning expired values

Mircea Markus mircea.markus at jboss.com
Mon Oct 17 17:40:22 EDT 2011


On 17 Oct 2011, at 18:21, Dan Berindei wrote:

> On Mon, Oct 17, 2011 at 7:51 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> I've noticed that every time we perform a get() operation (or any
>> other retrieval) the value is NOT returned to the client if it's
>> expired, which is going to receive a null instead.
>> 
>> It looks like that these checks are in place to prevent
>> a) a race condition with the eviction process
>> b) to not return very old values from a very large "wakeUpInterval"
>> between eviction activity
>> c) to load from cacheLoaders
>> 
>> Now for the first case, as a user of a caching library I would prefer
>> to get the value instead. Expiry is in place only to prevent me from
>> wasting memory, but this entry wasn't collected yet so why is
>> Infinispan denying me access to the value I want to retrieve? We're
>> introducing unneeded cache misses.
>> 
>> Since even with the current code we can not provide guarantees that we
>> won't ever return an expired entry (between  the check and the actual
>> return to user code we might be briefly suspended), I don't see why we
>> should not make it clear that the expiry timeout is a best-effort time
>> and relax our code checks a bit; there are many reasons to do so:
>> 
>> 1) avoid fictitious cache misses.
>> 
>> 2) Avoid the need to invoke a System.currentTimeMillis() for each
>> retrieval operation - that's expensive!
>> 
>> 3) Some operations like size() or values() now explicitly iterate the
>> whole result set twice to make sure all expired entries are removed.
>> This is unnecessary following the reasoning above.
>> 
>> Regarding the other cases:
>> b) We don't need to care imo. If people need more precision they
>> should use a lower wakeUpInterval.
> 
> I don't think this is an option, as a 5 seconds wakeUpInterval was
> deemed to short not long ago:
> https://source.jboss.org/viewrep/Infinispan/core/src/main/java/org/infinispan/config/Configuration.java?r1=9fe9a8cb6e49308b9e45f09b2f5324a7daefdee3&r2=9cda361dc6df7bcecde95abc31fcbab11f734360
perhaps a configuration option disabled by default? 
> 
>> c) We should keep this logic in CacheLoader, just because having an
>> aggressive wakeUpInterval might be very expensive in this case.
>> 
>> I'm asking as I've built a quick POC for ISPN-1459 but since now the
>> current time needs to be passed to the entry, I end up needing to
>> invoke the wall clock even for immortal cache entries making many
>> other use cases slower: not happy with that, I'd rather speed up both
>> use cases.
>> 
> 
> I guess you could pass in a Clock that lazily calls
> System.currentTimeMillis() and saves it for subsequent calls, but that
> will complicate things again.
Complicate by introducing an inaccuracy  on the "exact" time? Code-wise seems reasonably simple... 


More information about the infinispan-dev mailing list