>LUCENE-9660. Perhaps it's worth porting over to Solr too. +1 to this, I had been wondering about that!
The above explanation of the test suite error messages is great, and perhaps would be nice to have in "contributing" docs too. FWIW: the test-suite-level "no runnable tests" errors usually crop up for me when specifying tests with wildcard expressions, e.g.: `-Dtests.class='org.apache.solr.search.facet.*'` (with `DebugAgg` being the culprit in that case). I just ignore these "no runnable tests" errors (though perhaps there's a better way?). Not sure if that applies in this case (and come to think of it, I don't recall whether this applies to both `ant` or `gradle` builds), but I thought I'd mention it. Michael On Mon, Nov 22, 2021 at 11:59 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > > The test.seed will cause the randomized testing to choose the same > locale/timezone/encoding/etc so that if you're hitting a bug that only > shows up with swahili or for the kiribati timezone it will reproduce > reliably. > > Correct. Some things will be "derived" from this property at build > time (in gradle), other things will be derived from this seed at > runtime. Ideally we'd pick everything at runtime but some things can > only be done prior to the JVM launching (file.encoding, for example). > > > A) it's key to run cleanTest before running that "reproduce with" > command so that the build doesn't pass thinking the test is up to date (the > reproduce line probably ought to include this by default). > > This has been changed on Lucene side -- see LUCENE-9660. Perhaps it's > worth porting over to Solr too. > > > The thread leak version fails a test called "class method" and the > reproduce string always fails with a message about junit not finding tests, > because there isn't any test named .classMethod > > I can explain this. JUnit reports historically didn't have any way of > passing exceptions (failures) for non-test methods. This synthetic > "class method" is used by the test framework to report exceptions that > happened in class constructors, class-level before/after hooks and in > other scopes that are outside of the regular test methods. > > These errors are also aggregating: a thread leak error in Solr tests > is typically a result of some other, prior failure that leaves > unclosed file descriptors, non-interruptible threads running in the > background, etc. In an ideal world, a try-with-resources would close > these resources (such as thread pools), even if an exception is thrown > in the test body. Things being as they are, you get the source > exception first, followed by the framework complaining about the > inability to clean up test class threads (which results in completely > broken test suite isolation). > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
