On Nov 3, 2004, at 11:48 PM, Curt Arnold wrote:
I've worked the problem a bit further and think things are coming together. At this point, it looks like there was nothing that would have affected 1.2.9. I'll try to submit a bug report with the patch in the near future for hopeful inclusion in 1.3.
Sorry for not replying earlier. Not having looked into the ATDF code for about a million years, I can't really comment on the technical issues you raised with any semblance of accuracy. So I'll pass for the time being but will get back to you later. More below.
AbsoluteTimeDateFormat, DateTimeDateFormat, and ISO8601DateFormat all ignore timezone in their cache logic and have problems with pre-1970 dates in case you ever set your clock back that far. The approach that I have taken is to create a CachedDateFormat that wraps an arbitrary DateFormat and have removed the flawed cache logic. It does not attempt to share the same cached value among multiple layouts, but it would be difficult to do safely and I'm guessing that extra optimization would not offer a noticiable performance gain.
One of the benefits of this approach is that SimpleDateFormat's also benefit from caching. However, when running "ant -f performance.xml null" with Sun JDK 1.4.2 on Linux and the existing log4j, the SimpleDateFormat test appears competitive with ISO8601DateFormat. The log4j documentation suggested that SimpleDateFormat was substantially more expensive. So perhaps, the later JDK implementations have implemented similar logic internally or improved their performance or I am misreading the test. I'll try to run the performance test with an earlier JVM's or other platforms to see if the relative performance changes.
Actually, it appears that those classes AbsoluteTimeDateFormat, DateTimeDateFormat, ISO8601DateFormat) are obsolete (or nearly so). org.apache.log4j.pattern.DatePatternConverter always creates SimpleDateFormats even if you specify %d{ISO8601} which explains why the %d{ISO8601} times were so close to the %d{yyyy-MM...} test. Using CachedDateFormat to wrap the SimpleDateFormat created in DatePatternConverter did drop times from about 29 ms to 22 ms.
Given the problems with the current AbsoluteTimeDateFormat and similar classes, I think they probably should be just redefined as:
public class AbsoluteTimeDateFormat extends SimpleDateFormat {
public AbsoluteTimeDateFormat {
super("hh:mm:ss,SSS");
}
}if they can't be eliminated.
Digging a little deeper, it looks like I can set the timezone on the layout in the configuration. I haven't confirmed this with a test case yet.
DateLayout has a TimeZone attribute, however it isn't usable unless create your own extended layout. The only layout that extends DateLayout is TTCCLayout and it uses a relative date format.
What I'm thinking about is added a TimeZone attribute to PatternLayout and a setTimeZone(TimeZone) method to PatternConverter. After parsing the pattern converters, the pattern layout would call setTimeZone for all the converters. It would probably also be good to allow configuring the locale for the layout in a similar manner.
The configuration would look something like:
log4j.appender.gmtAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.gmtAppender.layout.ConversionPattern=%d{ISO8601}Z - %m%n
log4j.appender.gmtAppender.layout.TimeZone=GMT
log4j.appender.gmtAppender.locale=en-US
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
