[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644023#action_12644023
]
Yonik Seeley commented on SOLR-667:
-----------------------------------
The markAndSweep logic in the current code didn't replicate the logic I gave in
my example ConcurrentLRUCache, and it can remove a lot more than it should.
Specifically, my algorithm broke the results into 3 groups:
- those documents that are guaranteed to be in the top group (most recently
accessed)
- those documents guaranteed to be in the bottom group (immediately discard)
- those documents where you can't tell.
The current code reversed this logic, assuming that one can remove everything
that is not in the top group. This isn't valid though, as lastAccess isn't
uniform (and thus the size of the top group could be as small as 1).
> Alternate LRUCache implementation
> ---------------------------------
>
> Key: SOLR-667
> URL: https://issues.apache.org/jira/browse/SOLR-667
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java,
> ConcurrentLRUCache.java, SOLR-667-updates.patch, SOLR-667.patch,
> SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch,
> SOLR-667.patch, SOLR-667.patch
>
>
> The only available SolrCache i.e LRUCache is based on _LinkedHashMap_ which
> has _get()_ also synchronized. This can cause severe bottlenecks for faceted
> search. Any alternate implementation which can be faster/better must be
> considered.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
