[
https://issues.apache.org/jira/browse/SOLR-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-7585:
-------------------------------
Attachment: SOLR-7585.patch
New patch against trunk. Used DefaultSolrThreadFactory to fix the precommit.
Also hard-coded the number of threads in the new test to 10 so that the
unpatched ConcurrentLFUCache implementation fails the test even on systems with
less than four CPUs.
The CHANGES.txt assumes that the fix is going into version 5.2. I've asked the
release manager for 5.2 whether this fix is OK to backport.
> 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,
> 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]
