Maybe we should consider dropping our own logging implementation and use some existing logging library. Other people have put a lot more time and thought into logging than we have. And I don't think Daffodil has any special logging requirements that other loggers don't already have.
Thoughts? On 4/27/21 7:28 PM, Beckerle, Mike wrote: > Logging is highly suspicious for race conditions to me. > > This whole design is completely non-thread safe, and just doesn't make sense. > I think "with Logging" was just copied as a pattern from place to place. > > I just created https://issues.apache.org/jira/browse/DAFFODIL-2510 for this > issue. > ________________________________ > From: Beckerle, Mike <[email protected]> > Sent: Tuesday, April 27, 2021 3:28 PM > To: [email protected] <[email protected]> > Subject: Re: flakey windows CI build? Or real issue? > > This one line: > > [error] Test org.apache.daffodil.example.TestScalaAPI.testScalaAPI2 failed: > expected:<0> but was:<1>, took 0.307 sec > > For that test to fail an assertEquals, but only on one platform,... and it is > not reproducible. Is very disconcerting. > > The test has exactly 3 assertEquals that compare against 0. > > @Test > def testScalaAPI2(): Unit = { > val lw = new LogWriterForSAPITest() > > Daffodil.setLogWriter(lw) > Daffodil.setLoggingLevel(LogLevel.Info) > > ... > > val res = dp.parse(input, outputter) > > ... > assertEquals(0, lw.errors.size) > assertEquals(0, lw.warnings.size) > assertEquals(0, lw.others.size) > > // reset the global logging state > Daffodil.setLogWriter(new ConsoleLogWriter()) > Daffodil.setLoggingLevel(LogLevel.Info) > } > > So this test is failing sporadically because of something being written to > the logWriter (lw) that wasn't before. > > ________________________________ > From: Interrante, John A (GE Research, US) <[email protected]> > Sent: Tuesday, April 27, 2021 2:47 PM > To: [email protected] <[email protected]> > Subject: flakey windows CI build? Or real issue? > > Once you drill down into and expand the "Run Unit Tests" log, GitHub lets you > search that log with a magnifying lens icon and input search text box above > the log. Searching for "failed:" makes it easier to find the specific > failures. I found one failure and three warnings: > > [error] Test org.apache.daffodil.example.TestScalaAPI.testScalaAPI2 failed: > expected:<0> but was:<1>, took 0.307 sec > > [warn] Test assumption in test > org.apache.daffodil.usertests.TestSepTests.test_sep_ssp_never_1 failed: > org.junit.AssumptionViolatedException: (Implementation: daffodil) Test > 'test_sep_ssp_never_1' not compatible with implementation., took 0.033 sec > [warn] Test assumption in test > org.apache.daffodil.usertests.TestSepTests.test_sep_ssp_never_3 failed: > org.junit.AssumptionViolatedException: (Implementation: daffodil) Test > 'test_sep_ssp_never_3' not compatible with implementation., took 0.005 sec > [warn] Test assumption in test > org.apache.daffodil.usertests.TestSepTests.test_sep_ssp_never_4 failed: > org.junit.AssumptionViolatedException: (Implementation: daffodil) Test > 'test_sep_ssp_never_4' not compatible with implementation., took 0.003 sec > > Your previous run failed in the Windows Java 11 build's Compile step with a > http 504 error when sbt was trying to fetch artifacts: > > [error] > lmcoursier.internal.shaded.coursier.error.FetchError$DownloadingArtifacts: > Error fetching artifacts: > [error] > https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-native-packager/scala_2.12/sbt_1.0/1.8.1/jars/sbt-native-packager.jar: > download error: Caught java.io.IOException: Server returned HTTP response > code: 504 for URL: > https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-native-packager/scala_2.12/sbt_1.0/1.8.1/jars/sbt-native-packager.jar > (Server returned HTTP response code: 504 for URL: > https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-native-packager/scala_2.12/sbt_1.0/1.8.1/jars/sbt-native-packager.jar) > while downloading > https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-native-packager/scala_2.12/sbt_1.0/1.8.1/jars/sbt-native-packager.jar > > That error probably is just a flaky network or server problem. > > John > > -----Original Message----- > From: Steve Lawrence <[email protected]> > Sent: Tuesday, April 27, 2021 2:17 PM > To: [email protected] > Subject: EXT: Re: flakey windows CI build? Or real issue? > > I haven't seen failures in tests in a while, only thing I've noticed is > GitHub actions just stalling with no output. > > In the linked PR, I see the error: > > [error] Test org.apache.daffodil.example.TestScalaAPI.testScalaAPI2 > failed: expected:<0> but was:<1>, took 0.307 sec > > I wonder if these isAtEnd changes have introduced a race condition, or made > an existing race condition more likely to get hit? > > On 4/27/21 2:13 PM, Beckerle, Mike wrote: >> My PR keeps failing to build on Windows e.g., This failed the windows >> java8 build: >> https://github.com/mbeckerle/daffodil/actions/runs/789865909 >> <https://github.com/mbeckerle/daffodil/actions/runs/789865909> >> >> Previously today it failed the windows java 11 build. >> >> The errors were different. Earlier today it was in daffodil-io, the >> linked checks above it's in daffodil-sapi. >> >> In neither case is there an [error] identifying the specific test >> failing. Only a summary at the end indicating there were failures in that >> module. >> >> Is any of this expected behavior? I've seen mostly all 6 standard CI >> checks working of late on others' PRs. >> >> >> Mike Beckerle | Principal Engineer >> >> [email protected] <mailto:[email protected]> >> >> P +1-781-330-0412 >> > >
