[
https://issues.apache.org/jira/browse/FLUME-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244954#comment-14244954
]
Lenny Lofberg commented on FLUME-2556:
--------------------------------------
Problem could be that SimpleDateFormat instances are cached in BucketPath.java
and timezone is not always reset when a cached instance is retrieved.
For example if JUnit runs testDateFormatTimeZone() before testDateFormatHours()
(both use "%c" format) then timezone is set in the cached SimpleDateFormat
instance for "%c" ("EEE MMM d HH:mm:ss yyyy") when testDateFormatHours() gets
it from the cache.
Maybe timezone should be reset in getSimpleDateFormat() or in BucketPath.java
around line 320 if the provided value is null.
{code}
SimpleDateFormat format = getSimpleDateFormat(formatString);
if (timeZone != null) {
format.setTimeZone(timeZone);
}
{code}
> TestBucketPath.testDateFormatHours fails intermittently
> -------------------------------------------------------
>
> Key: FLUME-2556
> URL: https://issues.apache.org/jira/browse/FLUME-2556
> Project: Flume
> Issue Type: Bug
> Affects Versions: v1.5.1
> Reporter: Johny Rufus
> Assignee: Johny Rufus
> Fix For: v1.6.0
>
>
> TestBucketPath.testDateFormatHours sometimes results in the following error:
> org.junit.ComparisonFailure: expected:<Sat Jun 23 1[2]:00:00 2012> but
> was:<Sat Jun 23 1[9]:00:00 2012>
> at org.junit.Assert.assertEquals(Assert.java:125)
> at org.junit.Assert.assertEquals(Assert.java:147)
> at
> org.apache.flume.formatter.output.TestBucketPath.testDateFormatHours(TestBucketPath.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
