[
https://issues.apache.org/jira/browse/SOLR-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152641#comment-13152641
]
Shawn Heisey commented on SOLR-2889:
------------------------------------
My original approach wasn't working well, which is why I said I wasn't going to
be able to do it. Today I took a different approach, and the changes were
pretty easy. I just made copies of ConcurrentLRUCache.java and
FastLRUCache.java, then renamed and massaged them into LFU versions. The heart
of what I did was remove lastAccessed and turned it into an AtomicLong named
hits.
It does work as a cache for some simple hand-entered queries, but I need to do
some more extensive testing to see if evictions and warming are working as
expected before I upload it. I think I'll temporarily stick in some println
statements to watch what it's doing.
Some other things that need to be done that I'm not sure I'm qualified for (but
I will attempt):
- Test code.
- Abstracting out the common parts into parent classes.
> 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: [email protected]
For additional commands, e-mail: [email protected]