lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SOLR-667) Alternate LRUCache implementation
Date Fri, 26 Sep 2008 21:29:46 GMT

     [ https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Yonik Seeley updated SOLR-667:
------------------------------

    Attachment: ConcurrentLRUCache.java

Here is a prototype of an idea I've had for a while for an efficient concurrent LRU cache.
It is completely untested... consider it more "code as design".  It *should* feature faster
cleaning - O( n ) when it works well.

In addition to low and high water marks, it adds the concept of an "acceptable" water mark.
 A cleaning phase will try to go to the low water mark, but will be considered successful
if it hits the acceptable water mark.

This is coupled with a multi-pass cleaning phase.  From the comments:
{code}
    // if we want to keep at least 1000 entries, then timestamps of
    // current through current-1000 are guaranteed not to be the oldest!
    // Also, if we want to remove 500 entries, then
    // oldestEntry through oldestEntry+500 are guaranteed to be
    // removed.
{code}

The oldestEntry and newestEntry in the set of entries currently being considered is recorded
for each phase.  Entries that are new enough such that they are guaranteed to be kept are
immediately removed from consideration, and entries that are old enough such that they are
guaranteed to be removed are immediately removed (no sorting necessary).  After 2 phases of
this (configurable) and we still haven't removed enough entries, a priority queue is used
to find the oldest entries out of those remaining.

There are undoubtedly some other tricks we can use, but this was the best I could come up
with for now.

> 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
>             Fix For: 1.4
>
>         Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java, ConcurrentLRUCache.java,
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.


Mime
View raw message