[ 
https://issues.apache.org/jira/browse/SOLR-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557517#comment-14557517
 ] 

Maciej Zasada commented on SOLR-7585:
-------------------------------------

Yes, I saw SOLR-3393 before, but I assumed it will take a while to deprecate 
and remove the old class, and we're currently experiencing some exceptions 
because of this race condition :) Having in mind that you're working on more 
performant LFU cache, I tried to make changes as small and noninvasive as 
possible.

bq. it looks like markAndSweep was designed to reduce the cache size to 
lowerWaterMark.

Exactly. I believe that your change will actually reduce (sometimes) the cache 
size to be equal to {{lowerWaterMark -1}}, instead of equal to 
{{lowerWaterMark}}.

bq. Is it acceptable to avoid eviction if the current cache size is somewhere 
between the two watermarks?

Eviction will be only avoided if the size was less than or equal to 
{{upperWaterMark}}, which is exactly the same condition as in 
{{org.apache.solr.util.ConcurrentLFUCache#put}} method (L#139), where it's 
decided whether to call {{markAndSweep}} at all or not. Essentially, the same 
condition is checked after acquiring a lock to mitigate a race condition.

> ConcurrentLFUCache throws NoSuchElementException under a write-heavy load
> -------------------------------------------------------------------------
>
>                 Key: SOLR-7585
>                 URL: https://issues.apache.org/jira/browse/SOLR-7585
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 5.1
>            Reporter: Maciej Zasada
>            Priority: Minor
>         Attachments: SOLR-7585.patch, SOLR-7585.patch, SOLR-7585.patch
>
>
> Under a write-heavy load {{ConcurrentLFUCache}} throws 
> {{NoSuchElementException}}. The problem lies within 
> {{org.apache.solr.util.ConcurrentLFUCache#put}} method, which allows for a 
> race condition between the check and the call to {{markAndSweep}} method. 
> Despite that a thread must acquire a lock to perform sweeping, it's still 
> possible that multiple threads successfully detected a need for calling 
> markAndSweep. If they execute it sequentially, subsequent runs will fail with 
> {{NoSuchElementException}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to