[
https://issues.apache.org/jira/browse/LOG4J2-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849590#comment-15849590
]
Matt Sicker commented on LOG4J2-1805:
-------------------------------------
Ok, that makes sense. Thanks for the clarification.
> FixedDateFormat improvements
> ----------------------------
>
> Key: LOG4J2-1805
> URL: https://issues.apache.org/jira/browse/LOG4J2-1805
> Project: Log4j 2
> Issue Type: Improvement
> Components: Pattern Converters
> Affects Versions: 2.6
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> *Proposed changes:*
> * improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
> * expose {{FixedDateFormat::millisSinceMidnight}} as a public method
> In multi-threaded scenarios where time does not move forward monotonically,
> the implementation of {{FixedDateFormat::updateMidnightMillis}} can result in
> corrupted time stamps. In a project I am involved in we have a custom
> PatternConverter that uses FixedDateFormat to format the "event time". In
> these (artificial) tests, event time does not always move forward, so the
> {{updateMidnightMillis}} is called concurrently with varying values. This is
> not a production issue, but the implementation can be improved to be
> thread-safe without impacting performance by using double-checked locking.
> Making {{FixedDateFormat::millisSinceMidnight}} public would provide a
> performant and convenient way to strip off the date component. Useful for
> systems that are on Java 7 or for systems on Java 8 that don't want to
> construct a {{LocalTime}} object every time this value is required.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
