[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618072#action_12618072
]
noble.paul edited comment on SOLR-667 at 7/29/08 11:22 PM:
-----------------------------------------------------------
A POC implementation based on _ConcurrentHashMap_
* Gets are free
* Puts are free till it touches the high water mark . It is expensive (very
expensive) after the high watermark .
* To lighten the load on put an extra thread is employed to do a concurrent
mark and sweep
* there is a high-water-mark and a low-water-mark . The extra thread cleans
anything if low-water-mark is crossed. Put must removes if level crosses
high-water-mark
was (Author: noble.paul):
A POC implementation based on _ConcurrentHashMap_
Another one this is LRU. uses ConcurrentHashMap again
* Gets are free
* Puts are free till it touches the high water mark . It is expensive (very
expensive) after the high watermark .
* To lighten the load on put an extra thread is employed to do a concurrent
mark and sweep
* there is a high-water-mark and a low-water-mark . The extra thread cleans
anything if low-water-mark is crossed. Put must removes if level crosses
high-water-mark
> 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.
