[infinispan-dev] strictly not returning expired values

[Sanne Grinovero]

Not because of the cost of reading the clock, my main motivation is
that we artificially create cache misses which might be very expensive
to the client code.

On top of that, the fact that this check also has a cost - not arguing
how low - makes me wonder even more.

As I see it, it's unavoidable for a cache to provide a cache miss when
the data is gone, like GC'd, and we're not able to return it. It's
also reasonable to expire values and remove them to make sure we don't
run out of memory - but if there's a chance in which the value was not
garbage collected and we're able to return it, we should return it.
This has a potential good effect on the client application, and as it
turns out checking time is expensive too we will save some cost at
every get operation, but this is just in addition to the greater
benefit of reducing the ratio of cache misses.

Sanne

On 18 October 2011 11:05, Galder Zamarreño <galder at redhat.com> wrote:
> I'm not sure I'm understanding the motivation of this. Is it because you're finding System.currentTimeMillis to be expensive?
>
> If so, how expensive and in which scenarios (set up, test…etc)
>
> On Oct 17, 2011, at 6:51 PM, Sanne Grinovero 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.
>> 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.
>>
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>