[
https://issues.apache.org/jira/browse/SOLR-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557511#comment-14557511
]
Shawn Heisey commented on SOLR-7585:
------------------------------------
bq. both seem to be important for a cache. WDYT?
The benefits you noted certainly do sound like good things, but it looks like
markAndSweep was designed to reduce the cache size to lowerWaterMark. Is it
acceptable to avoid eviction if the current cache size is somewhere between the
two watermarks? Will anything strange happen in a situation where a cache is
defined with settings where any of the sizes/watermarks are not different
numbers?
FYI, the entire LFUCache implementation is due for replacement, because it's a
very slow and naive implementation, and I figured out a better way to do it.
See SOLR-3393.
> 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]
