[
https://issues.apache.org/jira/browse/SOLR-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148529#comment-13148529
]
Shawn Heisey commented on SOLR-2889:
------------------------------------
Two things:
1) After some thought, I have concluded that a straight LFU cache might fit my
needs perfectly, and it's a baby step towards ARC.
2) I took a quick look at some of the code. The code for cache trimming and
warming is in ConcurrentLRUCache.java, but the hits seem to be tracked in
{Fast}LRUCache.java. I think this means that the first step would be to
refactor things so that we have one or more base classes with common
functionality, which are then extended or imported by smaller classes that
implement LRU, LFU, and ARC.
Am I on the right track? Does this need another issue?
> Implement Adaptive Replacement Cache
> ------------------------------------
>
> Key: SOLR-2889
> URL: https://issues.apache.org/jira/browse/SOLR-2889
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 3.4
> Reporter: Shawn Heisey
> Priority: Minor
>
> Currently Solr's caches are LRU, which doesn't look at hitcount to decide
> which entries are most important. There is a method that takes both
> frequency and time of cache hits into account:
> http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache
> If it's feasible, this could be a good addition to Solr/Lucene.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
