Provide access to Expirable Entry age

[GoogleCodeExporter]

I would like to use MapMaper.expireAfterWrite, but I need access to the age of 
non-expired entries.  (See 
https://issues.apache.org/jira/browse/CASSANDRA-2070).

Original issue reported on code.google.com by jbel...@datastax.com on 17 Feb 2011 at 3:23

[GoogleCodeExporter]

Original comment by boppenh...@google.com on 21 Feb 2011 at 10:15

• Added labels: Type-Enhancement

[GoogleCodeExporter]

It would help to explain a little more about why this is needed.

Original comment by kevinb@google.com on 6 Apr 2011 at 3:25

[GoogleCodeExporter]

We need to track how old entries were, when they were removed by the expiration 
reaper instead of manually. Cassandra uses this to track how healthy its peers 
are.

Original comment by jbel...@datastax.com on 6 Apr 2011 at 4:16

[GoogleCodeExporter]

s/instead of manually/as well as manually/.  (That is, it's obvious how old 
expired entries are, or at least that they are no younger than the expiration 
time, but it's not possible to tell how old an entry was that we removed 
manually.)

Original comment by jbel...@datastax.com on 6 Apr 2011 at 4:17

[GoogleCodeExporter]

We've heard very little need for this aside from here. It would help to paint 
an even broader picture of what you're really trying to do. 

Would it be feasible for your CacheLoader (computation Function) keep its own 
track of timestamps?

Original comment by kevinb@google.com on 16 Jul 2011 at 8:17

• Changed state: Triaged

[GoogleCodeExporter]

Sure. But then the simplification to be gained by switching to a "standard" 
library class get much smaller, so we might as well not bother switching.

Original comment by jbel...@datastax.com on 16 Jul 2011 at 9:04

[GoogleCodeExporter]

I have a homebrewed cache framework that, for all of its faults, has a lot of 
this type of information available. It will show the number of hits, number of 
misses, the amount of time spent in the cache vs the dao to calculate time 
savings etc. And, of course, the age of the cache.

None of this information is used by the application, but its exposed (via a 
secured url) to our support team to help diagnose application issues. For 
example, by seeing when the cache was last refreshed, we can compare with when 
the backing data had changed, and determine if it was just an issue of a stale 
cache or if there was some other problem. We use these statistics to help tweak 
refresh intervals as well.

Original comment by raymond....@gmail.com on 18 Jul 2011 at 11:57

[GoogleCodeExporter]

Sure, "jbel...", if the advantages of MapMaker over what you've got are that 
slim, don't bother using it. So we're back to having a strong lack of evidence 
that this feature is needed. For now.

(Raymond: do you also expose *per-entry* data this way, like expiration times? 
That's the subject of the present issue. Here are the stats we'll be exposing 
in release 10: 
http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/cache/
CacheStats.html)

Original comment by kevinb@google.com on 19 Jul 2011 at 12:15

[GoogleCodeExporter]

Our homebrewed caches do not--they follow more of the "refresh the whole thing 
at regular intervals" strategy. 

Original comment by raymond....@gmail.com on 19 Jul 2011 at 11:09

[GoogleCodeExporter]

Original comment by fry@google.com on 10 Dec 2011 at 4:03

• Added labels: Package-Cache

[GoogleCodeExporter]

The way I would do this would be to implement my own cache interface, _backed 
by_ the Guava Cache implementation, in which the cache values are stored in a 
wrapper type that also remembers time since the value was created.

So something like

class MyCache {
  static final class TimeWrapper {
    Value value;
    long creationTime;
  }
  final Cache<Key, TimeWrapper> guavaCache;
  // delegating methods to guavaCache that take care of unwrapping TimeWrapper
  long nanosSinceCreation(Key key) {
    return System.nanoTime() - guavaCache.getUnchecked(key).creationTime;
  }
}

Original comment by wasserman.louis on 22 Dec 2011 at 6:10

[GoogleCodeExporter]

Memory use is important to us (10s to 100s of thousands of entries), so an 
extra wrapper to record redundant information because guava won't expose it is 
a non-starter.

Original comment by jbel...@datastax.com on 22 Dec 2011 at 6:48

[GoogleCodeExporter]

I hear you, we had a discussion regarding offering some sort of automatic 
refreshing (but with what policy?). Exposing something like Aged<V> was briefly 
discussed, didn't get much traction (the API would have to almost double), and 
the alternative that the user could create wrappers to track the age was the 
stop-gap alternative. I still think the Aged<V> has potential, especially if we 
could avoid API explosion by:
Cache<K, V> {
  Cache<K, Aged<V>> agedView();
}
Haven't thought this through, there may be lurking some deal breaker somewhere.

Original comment by jim.andreou on 23 Dec 2011 at 10:28

[GoogleCodeExporter]

I like the agedView idea, for what it's worth.

Original comment by jbel...@datastax.com on 23 Dec 2011 at 10:49

[GoogleCodeExporter]

I like agedView as well.

Original comment by wasserman.louis on 23 Dec 2011 at 11:20

[GoogleCodeExporter]

Well, if you like it, one of you could quickly scan Cache's and LoadingCache's 
methods to see which ones could become ill-defined by introducing Aged<V>, I 
haven't considered this more than 5 minutes, and there might be a devil in the 
details.

Original comment by jim.andreou on 24 Dec 2011 at 6:05

[GoogleCodeExporter]

Would the age always be updated as immediately as necessary?

Original comment by wasserman.louis on 24 Dec 2011 at 2:44

[GoogleCodeExporter]

The "age" would be reading the timestamp of the entry (the real entry object in 
the cache, this being just a view), so, yes.

Original comment by jim.andreou on 3 Jan 2012 at 8:44

[GoogleCodeExporter]

Original comment by fry@google.com on 16 Feb 2012 at 7:17

• Changed state: Acknowledged

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 May 2012 at 7:41

• Added labels: Type-Enhancement-Temp
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 May 2012 at 7:45

• Added labels: Type-Enhancement
• Removed labels: Type-Enhancement-Temp

[GoogleCodeExporter]

Original comment by kevinb@google.com on 22 Jun 2012 at 6:16

• Changed state: Research

[GoogleCodeExporter]

We're not ruling out agedView as a possible solution, but we're not yet 
convinced the problem requires a solution in common.cache at all.  The manual 
alternatives just seem fine for most cases.

If someone wants to craft a stronger argument showing what badness results from 
not having this, we can still consider reopening.

Original comment by kevinb@google.com on 9 Nov 2012 at 9:49

• Changed state: WontFix

[GoogleCodeExporter]

Issue 1484 has been merged into this issue.

Original comment by lowas...@google.com on 8 Aug 2013 at 10:49

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit