commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-326) Fix threading issue in X5455_ExtendedTimestampTest test class (a test for COMPRESS-210)
Date Sat, 24 Oct 2015 05:42:27 GMT


Stefan Bodewig commented on COMPRESS-326:

I think I've tracked it down.

Traditionally Java's {{ZipEntry#getTime}} returned the {{astModifiedTime}} from the archive
entry's header directly - this is why we adjust the time to the local time zone just like
InfoZIP would do since the test archive has been written by InfoZIP's zip.

Then came which changes the logic
of {{ZipEntry#getTime}} and now uses additional time fields InfoZIP or Microsoft's Compressed
Folders feature would use in order to get a better result.  I haven't tracked down which Java8
update has been the first one to receive the patch.

I'll try to adjust the test.

> Fix threading issue in X5455_ExtendedTimestampTest test class (a test for COMPRESS-210)
> ---------------------------------------------------------------------------------------
>                 Key: COMPRESS-326
>                 URL:
>             Project: Commons Compress
>          Issue Type: Bug
>            Reporter: Konstantin Kolinko
> The test for COMPRESS-210 is currently failing when Compress is built at Apache Gump.
> 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
> Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec <<<
> testSampleFile(
 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]
> 	at org.junit.Assert.assertEquals(
> 	at org.junit.Assert.assertEquals(
> 	at
> {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
> 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]

This message was sent by Atlassian JIRA

View raw message