lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <>
Subject [jira] [Commented] (SOLR-7585) ConcurrentLFUCache throws NoSuchElementException under a write-heavy load
Date Sat, 23 May 2015 20:15:17 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message