[
https://issues.apache.org/jira/browse/COMPRESS-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Kolinko updated COMPRESS-326:
----------------------------------------
Description:
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
was:
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.)
> 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)
