You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Erick Erickson (Jira)" <ji...@apache.org> on 2020/05/28 12:50:00 UTC
[jira] [Comment Edited] (SOLR-14498) BlockCache gets stuck not
accepting new stores
[ https://issues.apache.org/jira/browse/SOLR-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118611#comment-17118611 ]
Erick Erickson edited comment on SOLR-14498 at 5/28/20, 12:49 PM:
------------------------------------------------------------------
I'm gradually learning that when things totally stop making sense it's time to go to bed and look again in the morning.
The problem was that the gradle dependencies needed to be updated by updating versions.props, then running gradlew --write-lock in addition to creating the checksum file with either "ant jar-checksums" or "gradlew updateLicenses". Last night I just totally misread which one was being added and which deleted when I ran the unmodified gradle tasks.
It's awkward to have to update both, but at least with the checks we'll be in sync when we switch over.
was (Author: erickerickson):
I'm gradually learning that when things totally stop making sense it's time to go to bed and look again in the morning.
The problem was that the gradle dependencies needed to be updated by updating versions.props, then running gradlew updateLicenses. Last night I just totally misread which one was being added and which deleted when I ran the unmodified gradle tasks.
It's awkward to have to update both, but at least with the checks we'll be in sync when we switch over.
> BlockCache gets stuck not accepting new stores
> ----------------------------------------------
>
> Key: SOLR-14498
> URL: https://issues.apache.org/jira/browse/SOLR-14498
> Project: Solr
> Issue Type: Bug
> Components: query
> Affects Versions: 6.5, 6.6.5, master (9.0), 7.7.3, 8.5.1
> Reporter: Jakub Zytka
> Assignee: Andrzej Bialecki
> Priority: Major
> Fix For: 8.6
>
>
> {{BlockCache}} uses two components: "storage", i.e. {{banks}} and "eviction mechanism", i.e {{cache}}, implemented by caffeine cache.
> The relation between them is that "storage" enforces a strict limit for the number of entries (
> {{numberOfBlocksPerBank * numberOfBanks}}) whereas the "eviction mechanism" takes care of freeing entries from the storage thanks to {{maximumSize}} set for the caffeine cache to {{numberOfBlocksPerBank * numberOfBanks - 1}}.
> The storage relies on caffeine cache to eventually free at least 1 entry from the storage. If that doesn't happen the {{BlockCache}} starts to fail all new stores.
> As it turns out, the caffeine cache may not reduce it's size to the desired {{maximumSize}} for as long as no {{put}} or {{getIfPresent}} which *finds an entry* is executed.
> With a sufficiently unlucky read pattern, the block cache may be rendered useless (0 hit ratio):
> cache poisoned by non-reusable entries; new, reusable entries are not stored and thus not reused.
> Further info may be found in [https://github.com/ben-manes/caffeine/issues/420]
>
> Change in caffeine that triggers it's internal cleanup mechanism regardless of whether getIfPresent gets a hit has been implemented in [https://github.com/ben-manes/caffeine/commit/7239bb0dda2af1e7301e8f66a5df28215b5173bc]
> and is due to be released in caffeine 2.8.4
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org