I spun off a branch that uses CacheBuilder, just for kicks: https://github.com/fcrepo/fcrepo/blob/cachebuilder/fcrepo-server/src/main/java/org/fcrepo/server/storage/DOReaderCache.java
In any case, I think fcrepo-1058 is going to have to wait for 3.6.2 unless we make an exception for post-code freeze. We are going to have to push another release of Trippi, however, since something went awry with the 1.5.7 jars. On Aug 28, 2012, at 3:31 PM, Edwin Shin <[email protected]> wrote: > It's more that this issue provided an excuse to revisit DOReaderCache, rather > than any actual issue in your refactoring. > > Guava's CacheBuilder looks like a promising ready-made cache, backed by a > ConcurrentMap: > http://code.google.com/p/guava-libraries/wiki/CachesExplained > > and is limited to just the one library (admittedly ~1.8MB), but no further > dependencies. > > We could pretty much just have: > > Cache<String, DOReader> cacheMap = > CacheBuilder.newBuilder().maximumSize(maxSize) .expireAfterAccess(maxSeconds, > TimeUnit.SECONDS).build(); > > > > On Aug 28, 2012, at 2:08 PM, frank <[email protected]> wrote: > >> I don't really mind using a diff. impl for the underlying data structure >> currently it's using ConcurrentHashMap from java.util.concurrent which i >> have used for many cache implementations. the cache class itself i think was >> not reinventing the wheel. it's a standard lru implememtation for DoReaders. >> Ready made caches like ehcache on the other hand introduce an IMHO far too >> large overhead for such a simple cache. >> But using SoftReferences for the cache entries would probably make sense in >> situation with low memory... >> -- >> *frank asseg* >> softwareentwicklung >> feichtmayrstr. 37 >> 76646 bruchsal >> tel.: ++49-7251-322-6073 >> fax.: ++49-7251-322-6078 >> mail: [email protected] >> web: http://www.congrace.de/ >> >> Edwin Shin <[email protected]> wrote: >> Looking at this again over my morning coffee, I think we ought to seriously >> consider re-implementing the caching using a synchronized LinkedHashMap or >> opt for Google's ConcurrentLinkedHashMap >> (http://code.google.com/p/concurrentlinkedhashmap/). >> >> I like the latter: well-documented, tested and now integrated in Guava. >> >> LRU caches are pretty well-tread territory and I'd rather not re-invent the >> wheel, other than as an instructional exercise. >> >> On Aug 28, 2012, at 1:42 AM, Edwin Shin <[email protected]> wrote: >> >>> Not sure if Chris is back from holiday. >>> >>> i did a really cursory review--sorry, I'm about to crash for the night. >>> Looks generally ok to me, but I didn't thoroughly review the expiry of >>> cache items, so someone with fresher eyes might want to have a look. >>> >>> >>> On Aug 27, 2012, at 2:33 PM, "Asseg, Frank" <[email protected]> >>> wrote: >>> >>>> Hola Guys, >>>> >>>> don't really know what to do about fcrepo-1058.. >>>> @Chris did you a chance to review the fix? can i commit this into master? >>>> >>>> Have fun! >>>> >>>> Frank >> ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
