inviting semi-public comment on a change I'm working on: SOLR-8803
https://issues.apache.org/jira/browse/SOLR-8803 In which I change Solr 9.2.0 so it crashes on OOME when using bin/solr or bin\solr.cmd and creates a crash file that DOES show the resource which was depleted to cause the OOME. Seen far too often that Solr dies from OOME and there is no exception logged anywhere. The patch looks good to me, and I have tested it on both Linux and Windows. I'm opening it up for this wide review because it's a little bit of a fundamental part of Solr to be changing, and I want to make sure I am not overlooking something. I was a little dismayed that I had to give the manageProcess RuntimePermission to the security manager, just to get Java to let me have the JVM's PID. I am hoping that what I can get from Java without adding permissions, or by adding a far more granular permission, is the full path of the crashfile. Three days ago, I asked hotspot-gc-...@openjdk.net if that was possible and have gotten no reply, not even "this mailing list is not the right place for that question." Because Solr should not be running with administrator privileges if our recommendations are being followed, manageProcess might be OK, but others might not like my bikeshed color. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: [JENKINS] Solr-main-Linux (64bit/jdk-16.0.2) - Build # 7849 - Still Unstable!
Most likely one of my commits today caused this. Apparently I didn't run the hdfs tests... My guess is commons-text or Gradle. I won't be able to look at this until tomorrow at the earliest. Kevin Risden On Sat, Oct 15, 2022, 19:55 Policeman Jenkins Server wrote: > Build: https://jenkins.thetaphi.de/job/Solr-main-Linux/7849/ > Java: 64bit/jdk-16.0.2 -XX:-UseCompressedOops -XX:+UseSerialGC > > 12 tests failed. > FAILED: > org.apache.solr.hdfs.cloud.api.collections.HdfsCloudIncrementalBackupTest.classMethod > > Error Message: > java.lang.Exception: Error starting up MiniSolrCloudCluster > > Stack Trace: > java.lang.Exception: Error starting up MiniSolrCloudCluster > at __randomizedtesting.SeedInfo.seed([183F02B0C82BE2D2]:0) > at > org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:767) > at > org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:362) > at > org.apache.solr.cloud.MiniSolrCloudCluster$Builder.build(MiniSolrCloudCluster.java:1233) > at > org.apache.solr.cloud.MiniSolrCloudCluster$Builder.configure(MiniSolrCloudCluster.java:1205) > at > org.apache.solr.hdfs.cloud.api.collections.HdfsCloudIncrementalBackupTest.setupClass(HdfsCloudIncrementalBackupTest.java:129) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:886) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:902) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) > at > org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:80) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at > org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.tests.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.tests.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) > at > org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43) > at > org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44) > at > org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60) > at > org.apache.lucene.tests.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.lambda$forkTimeoutingTask$0(ThreadLeakControl.java:850) > at java.base/java.lang.Thread.run(Thread.java:831) > Suppressed: java.lang.NoClassDefFoundError: Could not initialize > class org.apache.hadoop.shaded.com > .sun.xml.bind.v2.runtime.reflect.opt.Injector > at org.apache.hadoop.shaded.com > .sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:83) > at org.apache.hadoop.shaded.com > .sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:176) > at org.apache.hadoop.shaded.com > .sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(A
Re: inviting semi-public comment on a change I'm working on: SOLR-8803
I put a PR up that builds on Shawn's work and doesn't need manage process permissions. Kevin Risden On Sat, Oct 15, 2022, 18:07 Shawn Heisey wrote: > https://issues.apache.org/jira/browse/SOLR-8803 > > In which I change Solr 9.2.0 so it crashes on OOME when using bin/solr > or bin\solr.cmd and creates a crash file that DOES show the resource > which was depleted to cause the OOME. Seen far too often that Solr dies > from OOME and there is no exception logged anywhere. > > The patch looks good to me, and I have tested it on both Linux and > Windows. I'm opening it up for this wide review because it's a little > bit of a fundamental part of Solr to be changing, and I want to make > sure I am not overlooking something. > > I was a little dismayed that I had to give the manageProcess > RuntimePermission to the security manager, just to get Java to let me > have the JVM's PID. I am hoping that what I can get from Java without > adding permissions, or by adding a far more granular permission, is the > full path of the crashfile. Three days ago, I asked > hotspot-gc-...@openjdk.net if that was possible and have gotten no > reply, not even "this mailing list is not the right place for that > question." Because Solr should not be running with administrator > privileges if our recommendations are being followed, manageProcess > might be OK, but others might not like my bikeshed color. > > Thanks, > Shawn > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
