I found a way to disable the log4shell patch on my work machine, and got a pass:
SUCCESS! [1:00:57.577806] I don't think we need to be concerned about trying to adapt to this thing. It only conflicts with the test framework, and devs can turn it off to run tests. Somehow our automated builds don't seem to be affected. so, +1 from me On Fri, Mar 18, 2022 at 10:38 PM Patrick Zhai <[email protected]> wrote: > > Hi Julie, thanks for summarizing the issues, for 4, as far as I understand, > there's nothing that needs to be changed on lucece's end. We're still having > trouble running the smoke test on Amazon's machine, but I've tried it on my > own machine and it passed. > > So here's my +1. SUCCESS! [0:59:35.291572] > > > On Fri, Mar 18, 2022 at 2:26 PM Julie Tibshirani <[email protected]> wrote: >> >> Hi everyone, people have run into several test failures, here's a summary to >> make it easier to follow: >> >> Some tests can be very slow with certain random parameters, and this can >> cause the smoke tester to take several hours -- this seems like a test-only >> problem, and we're working to address it in >> https://issues.apache.org/jira/browse/LUCENE-10473. >> TestMatchAllDocsQuery#testEarlyTermination can fail with assertion -- this >> is a test-only issue, and has already been fixed in >> https://issues.apache.org/jira/browse/LUCENE-10472. >> TestIndexWriterMergePolicy#testStressUpdateSameDocumentWithMergeOnGetReader >> can OOM -- this is a known issue and is not expected to occur outside of >> tests (https://issues.apache.org/jira/browse/LUCENE-10088) >> Security manager issues from Amazon's log4shell patch -- not sure this >> requires a change on our end? It sounds like Mike is investigating the >> issues now (thanks!) >> Test suite may also stall on some machines? -- Uwe mentioned "Looks like a >> problem with the test or some wrong assumption or some missing synchronized >> block (the Policeman Jenkins machine has many cores, so issues with not >> synchronized cache lines can happen easily)." Is this a different problem >> from #1 where we just have slow tests? I'm not sure if this is something we >> want to investigate as part of the release or if we think it can wait. >> >> Thanks, >> Julie >> >> On Fri, Mar 18, 2022 at 12:17 PM Michael Sokolov <[email protected]> wrote: >>> >>> We had to do a workaround in our internal test suites by setting a >>> system property to trick this thing into not running; Maybe we can >>> apply that also here... >>> >>> On Fri, Mar 18, 2022 at 3:12 PM Dawid Weiss <[email protected]> wrote: >>> > >>> > I think this is Amazon trying to cope with log4shell - they've added >>> > external instrumentation. >>> > >>> > On Fri, Mar 18, 2022 at 7:51 PM Robert Muir <[email protected]> wrote: >>> > > >>> > > >> 2> at >>> > > >> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >>> > > >> 2> at Log4jHotPatch.asmVersion(Log4jHotPatch.java:71) >>> > > >> 2> at Log4jHotPatch.agentmain(Log4jHotPatch.java:93) >>> > > >> 2> ... 6 more >>> > > > >>> > > > >>> > > > Does anyone have an idea? >>> > > > >>> > > >>> > > Your JVM is broken, look at this Log4jHotPatch stuff causing trouble. >>> > > >>> > > --------------------------------------------------------------------- >>> > > To unsubscribe, e-mail: [email protected] >>> > > For additional commands, e-mail: [email protected] >>> > > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [email protected] >>> > For additional commands, e-mail: [email protected] >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
