[
https://issues.apache.org/jira/browse/COMPRESS-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961973#comment-14961973
]
Stefan Bodewig commented on COMPRESS-326:
-----------------------------------------
This problem's been on my radar for a while, I just couldn't find a big enough
slice of time to look into it. Yes, it is the Java version. It also happens
locally - the test fails with recent enough Java8s and 9s, passes with older
Java8s and < 8. I've been speculation about a change to the java.util.zip
package, but see above.
Unfortunately making the SimpleDateFormat non-static doesn't help (the test
should be single-threaded anyway).
> Fix threading issue in X5455_ExtendedTimestampTest test class (a test for
> COMPRESS-210)
> ---------------------------------------------------------------------------------------
>
> Key: COMPRESS-326
> URL: https://issues.apache.org/jira/browse/COMPRESS-326
> Project: Commons Compress
> Issue Type: Bug
> Reporter: Konstantin Kolinko
>
> The test for COMPRESS-210 is currently failing when Compress is built at
> Apache Gump.
> http://vmgump.apache.org/gump/public/commons-compress/commons-compress-test/index.html
> It says that the last success was on 2015-10-06T00:00:09,
> it started failing at 2015-10-06T12:00:09
> and as of now the failure state is persistent for 22 runs (which means ~11
> days).
> The failure:
> {noformat}
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Apache Commons Compress 1.11-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> <...>
> Running org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest
> Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec <<<
> FAILURE! - in
> org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest
> testSampleFile(org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest)
> Time elapsed: 0.027 sec <<< FAILURE!
> org.junit.ComparisonFailure: expected:<2105-01-01/0[0:00:02] +0000> but
> was:<2105-01-01/0[8:00:01] +0000>
> at org.junit.Assert.assertEquals(Assert.java:116)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at
> org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestampTest.testSampleFile(X5455_ExtendedTimestampTest.java:171)
> {noformat}
> Reviewing rhe code of the test class, its usage of `SimpleDateFormat
> DATE_FORMAT` field is wrong. The field is declared as "static". A
> SimpleDateFormat is not thread-safe, so it must not be shared between tests,
> as some testing configurations may run several tests in parallel.
> A simple fix will be to remove "static" from declaration of that field and
> its initialization block, so that each running instance of the test gets its
> own copy of SimpleDateFormat class.
> (I am not sure whether this bug is the actual cause of the test failure. I do
> not see any reconfigurations of test environment on 2015-10-06. *Update*:
> according to gump-general mailing list \[1], on Oct 06 the Java runtime used
> to run Gump was updated to the latest Java 8 release)
> \[1]
> http://mail-archives.apache.org/mod_mbox/gump-general/201510.mbox/%3C5613A448.8040109%40apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
