[
https://issues.apache.org/jira/browse/SOLR-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557567#comment-14557567
]
Shawn Heisey commented on SOLR-7585:
------------------------------------
The test fails precommit.
[forbidden-apis] Forbidden method invocation:
java.util.concurrent.Executors#newFixedThreadPool(int) [Spawns threads with
vague names; use a custom thread factory (Lucene's NamedThreadFactory, Solr's
DefaultSolrThreadFactory) and name threads so that you can tell (by its name)
which executor it is associated with]
[forbidden-apis] in org.apache.solr.search.TestLFUCache
(TestLFUCache.java:371)
I'm looking at existing uses of DefaultSolrThreadFactory trying to figure out
how to adapt it to this test code, but it's not making sense to me.
> 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
>
>
> 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]
