Hi Michael, thanks for your input! Replacing the JDK with a new version is a regular procedure here and yes, I am aware of the issues because we ran into them when we introduced that procedure đ So no, what I see with that 361 version is not related to Solr not picking up the new JDK. What rather worries me when googling that stuff are references like https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8258954 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8245543, looks like a longer struggle. Well, we shall see with version 371 ... Best regards Hans
-----Ursprßngliche Nachricht----- Von: Michael Gibney <[email protected]> Gesendet: Mittwoch, 1. März 2023 16:10 An: [email protected] Betreff: Re: Solr 8.11.2 / Oracle JDK 1.8.0_361 This may not be the issue for you, but I've seen this kind of error before when the jdk is swapped out on the filesystem under a running process on an old jdk. Make sure you restart the solr process to pick up the new jdk once it's in place. (The old process will continue to run with the deleted filehandles, but when new internal classes are lazily loaded, they're looked up via filesystem path of the deleted jdk, so they won't be found). On Wed, Mar 1, 2023 at 1:58 AM Gruenberger, Hans <[email protected]> wrote: > > Hi folks, > > For reasons not to be discussed I am stuck with the combination JDK 8 and > Solr 8.11.2. Everything looks good as long as I use JDK 1.8.0_351 but Solr > won't start properly as soon as I switch to JDK 1.8.0_361 and solr.log file > contains a Java stack trace with e.g. this particular entry: > > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > jdk.internal.platform.cgroupv2.CgroupV2Subsystem > > I know that 361 has a known issue (supposedly fixed with build 32, but > looking at my log I doubt this), so I am just curious whether somebody else > ran into that problem. > > Best regards > > Hans > > >
