[
https://issues.apache.org/jira/browse/SOLR-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118019#comment-17118019
]
Mike Drob commented on SOLR-14498:
----------------------------------
This causes precommit failures on master, need to update the version in a few
more places.
{noformat}
> Task :solr:core:validateJarChecksums FAILED
FAILURE: Build failed with an exception.
* Where:
Script '/Users/mdrob/code/lucene-solr/gradle/validation/jar-checks.gradle'
line: 195
* What went wrong:
Execution failed for task ':solr:core:validateJarChecksums'.
> Dependency checksum validation failed:
- Dependency checksum missing
('com.github.ben-manes.caffeine:caffeine:2.8.0'), expected it at:
/Users/mdrob/code/lucene-solr/solr/licenses/caffeine-2.8.0.jar.sha1
{noformat}
{noformat}
mdrob-imp:~/code/lucene-solr $ git grep 2[.]8[.]0
versions.lock:com.github.ben-manes.caffeine:caffeine:2.8.0 (1 constraints:
0c050d36)
versions.props:com.github.ben-manes.caffeine:caffeine=2.8.0
{noformat}
I'm not actually sure what the correct way to update these is, however.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
