expireAfterRead question

[joanbalaguero]

Hi Ben,

In our removalListener, how can I know if an expired entry comes from an 'expireAfterCreate' or an 'expireAfterRead? is the RemovalCause different?

Another thing I'm probably doing wrong. This is my Expiry:

expireAfter(new Expiry<String, CacheValue>() {
  expireAfter(new Expiry<String, CacheValue>() {
    public long expireAfterCreate(String key, CacheValue value, long currentTime) {
     System.out.println(fdf.format(System.currentTimeMillis()) + " :: expireAfterCreate: " + (method.isL2Cache() ? value.getCacheTimeL2() : value.getCacheTime()));
     return TimeUnit.MILLISECONDS.toNanos(method.isL2Cache() ? value.getCacheTimeL2() : value.getCacheTime());
    }
    public long expireAfterUpdate(String key, CacheValue value, long currentTime, long currentDuration) {
     System.out.println(fdf.format(System.currentTimeMillis()) + " :: expireAfterUpdate: " + (method.isL2Cache() ? value.getCacheTimeL2() : value.getCacheTime()));
     return TimeUnit.MILLISECONDS.toNanos(method.isL2Cache() ? value.getCacheTimeL2() : value.getCacheTime());
    }
    public long expireAfterRead(String key, CacheValue value, long currentTime, long currentDuration) {
     System.out.println(fdf.format(System.currentTimeMillis()) + " :: expireAfterRead: " + (method.getMaxIdleTimeInMilis() > 0 ? method.getMaxIdleTimeInMilis() : Integer.MAX_VALUE));
     return TimeUnit.MILLISECONDS.toNanos(method.getMaxIdleTimeInMilis() > 0 ? method.getMaxIdleTimeInMilis() : Long.MAX_VALUE);
    } 

The removalListener is not using the 'expireAfterRead'.

For example, I have a cache with a 1 minute cache time and 30 seconds of max idle time. When I insert an entry, I see the 'expireAfterCreate' trace, and after 1 minute I see the 'removalListener' trace, but I should see this trace after 30 seconds because there were no reads/writes on this period, so the max idle time should have been triggered.

Thanks,

Joan.

[ben-manes]

Hi Joan,

The expiration policy maintains a single per-entry timestamp so that each operation mutates this lifetime value. In your test case there were no reads, so it did not reset the timestamp to cause it to evict earlier. The currentDuration is passed in to allow a method to return that to indicate no changes.

This generally gives the desired behavior and helps us minimize the memory overhead. If you wanted distinct policies like you described, then you could retain the multiple fields on the value yourself and return the minimum duration. Similarly if you wanted to indicate what dominant expiration was in play to indicate within the removal listener what caused the expiration event. It is a little bit more code and usually not helpful other than for gaining api familiarity.

[joanbalaguero]

Hi Ben,

Ok, done as you have said, working fine ... Thanks!!

Joan.

[joanbalaguero]

Sorry, just one more question: the currentTime and currentDuration parameters .. what are they? I tried to convert them to dates to see what they represent, and I see dates from 1970.

[ben-manes]

currentTime Is the reading from the Ticker, typically System.nanoTime() unless disabled or faked.
currentDuration is the remaining nanos until expired.

nanos is safer to use for local duration calculations due to being monotonic, whereas millis can fluctuate or be reset as wall clock time. However since nanos has an arbitrary starting point, it’s not useful for external calculations where the shared wall clock reference is needed. In that case you can ignore currentTime as not helpful and query currentTimeMillis() to calculate the duration.