[
https://issues.apache.org/jira/browse/SOLR-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149179#comment-13149179
]
Shawn Heisey commented on SOLR-2889:
------------------------------------
FastLRUCache uses ConcurrentLRUCache, which includes a full class for a cache
entry. A new member could be added to CacheEntry pretty easily to track usage,
but the rest of the code would have to me modified to use it. Making sure it's
all thread-safe would probably be the hard part.
LRUCache relies on the alternate sort order on LinkedHashMap, so it would not
be as simple to add usage tracking.
Something I noticed along the way: The solrj tree seems like an odd place for
ConcurrentLRUCache, because nothing else in that section uses it (directly at
least).
> 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
