Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <574918199.1227392804361.JavaMail.jira@brutus>
Date: Sat, 22 Nov 2008 14:26:44 -0800 (PST)
From: "Yonik Seeley (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Commented: (SOLR-667) Alternate LRUCache implementation
In-Reply-To: <1302026290.1217398411543.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.