[ https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649982#action_12649982 ]
Yonik Seeley commented on SOLR-667: ----------------------------------- Does this have a thread leak? Where is FastLRUCache.destroy() ever called? It's called from the finalizer (yuck), *but* that finalizer will never be called because the cleaning thread references the cache (the definition of liveness). Issues with having the cache deal with the thread lifecycle is why I previously recommended exploring the use of an Executor that the user passes in. > 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: Yonik Seeley > Fix For: 1.4 > > Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java, > ConcurrentLRUCache.java, SOLR-667-alternate.patch, SOLR-667-alternate.patch, > 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, > 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.