[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618715#action_12618715
]
Yonik Seeley commented on SOLR-667:
-----------------------------------
bq. Gets are free
Not entirely... there are a few memory barriers that make things thread safe,
so I wouldn't call it "free" (since this branched off of another issue where
some had the idea that one could get away without any sort of locks or memory
barriers).
It's a good approach in genera, and should scale better with many CPUs under
very high lookup load. But I'm not sure that it should use a separate cleaner
thread... and if it does, I don't think it should be scheduled.
After we got those details worked out, then we'd need a SolrCache
implementation that uses it. Given where we are in the release cycle (and that
the cache contention issue is only affecting 1 person that I've seen), I think
this should want until after 1.3
> 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
> Attachments: ConcurrentLRUCache.java
>
>
> 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.
