[
https://issues.apache.org/jira/browse/SOLR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153249#comment-13153249
]
Shawn Heisey commented on SOLR-2906:
------------------------------------
I've been trying to find my bug. Looking back at the original LRU
implementation, I have no idea how it's working.
When a CacheEntry is created in the LRU code, one of the values sent in is an
incremented stats.accessCounter, which gets called lastAccessed in the new
object. When it is later used in markAndSweep, it is used in simple math along
with the number of items that we want to keep/remove. This is very confusing,
and I can't see how it could ever work. It might be that part of the code is
simply skipped because of the way the math happens to work out.
When I changed it around to use hitcounts, those counts are also used in the
previously mentioned simple math, and I believe that results in some very weird
behavior, such as removing most (or possibly all) of the cache entries.
It appears that this idea is a lot more complicated than I originally thought,
and that the current code needs to be at least partially rewritten.
> Implement LFU Cache
> -------------------
>
> Key: SOLR-2906
> URL: https://issues.apache.org/jira/browse/SOLR-2906
> Project: Solr
> Issue Type: Sub-task
> Components: search
> Affects Versions: 3.4
> Reporter: Shawn Heisey
> Priority: Minor
> Attachments: ConcurrentLFUCache.java, FastLFUCache.java
>
>
> Implement an LFU (Least Frequently Used) cache as the first step towards a
> full ARC cache
--
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
