[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618768#action_12618768
]
Noble Paul commented on SOLR-667:
---------------------------------
bq.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.
Thanks for the comments. I agree with you . I devised this approach because
some user reported that heavy cache lookups are slowing things down for him.
The cost benefit analysis is yet to be studied. Separate cleaner thread is
optional in the implementation . I am yet to study the cost of sorting over a
hundred thousand entries. Do you recommend that the cleaner thread just keep
running forever? That is fine, so there should be a sleep for the thread?
BTW is the executorservice very expensive?
I did not provide a SolrCache implementation because that is going to be drown
the approach in details.
bq. I think this should want until after 1.3
True. This is not marked for 1.3. But this can definitely live as a patch and
anyone who needs it would benefit from it
> 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.
