[
https://issues.apache.org/jira/browse/SOLR-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689359#action_12689359
]
Ben Manes commented on SOLR-1082:
---------------------------------
Yes, the LRU implementation in my CLHM is less than ideal, as I had originally
intended to use a back-tracking algorithm but I just didn't trust it. This is
why I use the Second Chance policy in our production environment, as it
provides LRU-like efficiency without any bad tricks. I consider the watermark
approach taken by ConcurrentLRUCache to be an equally bad trick, because it
plays Russian rollet for which caller takes the hit. So I was pounding my head
trying to figure out how to do it elegantly, experimenting along the way, and
hence the warning in the JavaDoc.
If you look at the google project page for the CLHM (see JavaDoc) you'll see
that I've posted a document with a fairly nice design that should resolve your
concerns. There are a few optimizations that can be made that I should update
the document with, and I am toying with a rework that may prove to be lock
free. Of course finding the actual bandwidth to implement the algorithm has
been challenging. But its a hobby project, or at least that's my excuse! :-)
Since Greg Luck found enough value in the current, though flawed,
implementation he adopted it. Just like I'm sure that Solr found enough value
in the ConcurrentLRUCache - neither design is perfect, but good enough for now.
Hopefully I'll find some time shortly to continue working on my project and
Ehcache can adopt a better version in a later release.
> Refactor caching layer to be JCache compliant (jsr-107). In particular,
> consider using ehcache implementation
> -------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-1082
> URL: https://issues.apache.org/jira/browse/SOLR-1082
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.5
> Reporter: Kaktu Chakarabati
>
> overhaul the caching layer to be compliant
> with the upcoming Jcache api (jsr-107).
> In specific, I've been experimenting some with ehcache
> (http://ehcache.sourceforge.net/ , Apache OS license) and it seems to be a
> very comprehensive implementation, as well as fully compliant with the jcache
> API.
> I think the benefits are numerous: in respect to ehcache itself, it seems to
> be a very mature implementation, supporting most classical cache schemes as
> well as some interesting distributed cache options (and of course,
> performance-wise its very lucrative in terms of reported multi-cpu scaling
> performance and some of the benchmark figures they show).
> Further, abstracting away the caches to use the jcache api would probably
> make it easier in the future to make the whole caching layer more easily
> swappable with some other implementations that will probably crop up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
