[
https://issues.apache.org/jira/browse/SOLR-16463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17620626#comment-17620626
]
Uwe Schindler edited comment on SOLR-16463 at 10/19/22 10:13 PM:
-----------------------------------------------------------------
Thanks, Jan. This is exactly my own opinion on the situation. In general the
appoach here is fine. If you have many reports with same issue in some method,
we can always use the workaround (just make sure that *whole* hs_err.pid is
posted; people tend to only report the crash, but forget that we are no C
coders but Java coders and we need Java function names not arbitrary C++ code
stack traces and SIGXXX codes or compilation ther stack dumps). For this issue
excluding this method will for sure disable the bug for that compilation unit.
Others could still exist, but we would have some instances of reports on them.
More data would be good, but posted hserr files all have same information by
different users and JVM versions (Microsoft, Adoptium/Temurin, Oracle,...).
I just want to add: In JDK 17 (and also JDK 11) are so many bugs we have seen,
some are already fixed in 17, but still existing in 11 (just look at the daily
failures by Lucene's tests running all variants of 11 to 20-ea on 9.x branch).
If we really would like to be safe: Let's go back to 8! - oh wait, JDK 8 is
also buggy! :P
It would just be good if we could get some feedback from users of mailing list.
was (Author: thetaphi):
Thanks, Jan. This is exactly my own
I just want to add: In JDK 17 (and also JDK 11) are so many bugs we have seen,
some are already fixed in 17, but still existing in 11 (just look at the daily
failures by Lucene's tests running all variants of 11 to 20-ea on 9.x branch).
If we really would like to be safe: Let's go back to 8! - oh wait, JDK 8 is
also buggy! :P
It would just be good if we could get some feedback from users of mailing list.
> Serious crash on JDK17+ due to JIT on caffeinecache
> ---------------------------------------------------
>
> Key: SOLR-16463
> URL: https://issues.apache.org/jira/browse/SOLR-16463
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
> Affects Versions: 9.0
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Blocker
> Fix For: 9.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Solr 9+ under JDK 17+ may crash frequently, during JVM Hotspot optimization
> of caffeine cache class.
> This is due to a JDK bug
> ([https://bugs.openjdk.org/browse/JDK-8285835|https://bugs.openjdk.org/browse/JDK-8285835)]),
> but may not be fixed soon in JDK17, so we should make a workaround to
> protect our users. The bug is also reported in caffeine project
> ([https://github.com/ben-manes/caffeine/issues/797]).
> So there are a few possible ways to avoid this
> * Run Solr 9 on JDK 11
> * Do not use caffeine cache, find some replacement
> * Caffeine cache releases a new version that do not suffer the issue, and
> solr uses that
> * Instruct JDK to not optimize that class, using JDK option
> {{-XX:CompileCommand=exclude,com.github.benmanes.caffeine.cache.BoundedLocalCache::put}}
> See users list for examples of this issue seen in the wild:
> [https://lists.apache.org/thread/wg7qtkddd1t5h08okj7gm9qbrpdf0ox6]
> Docker users can set SOLR_OPTS with the JDK option above. Patching the
> official Dockerfile to include this may be the least intrusive fix
> short-term. We should also document the issue on website and perhaps docker
> hub to provide users with a workaround.
> For 9.1 we can hardcode the JDK flag in bin/solr.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
