[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644389#action_12644389
]
Yonik Seeley commented on SOLR-667:
-----------------------------------
Nobe, your latest patch contains code like this:
{code}
if (!markAndSweepLock.tryLock()) return;
long oldestItem = this.oldestItem;
[...]
markAndSweepLock.unlock();
this.oldestItem = oldestItem;
{code}
oldestItem isn't volatile (and doesn't need to be if accessed correctly).
The lock will also serve as a read barrier, so the first part is OK.
The unlock will serve as a write barrier, but the set of oldestItem comes after
it (not OK... another thread may not see the value).
Changing the order (the write to oldestItem before the unlock) will ensure that
the next thread that crosses a read barrier will see the new value.
> 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-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
>
>
> 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.
