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