[
https://issues.apache.org/jira/browse/LOG4J2-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978830#comment-15978830
]
Anthony Maire commented on LOG4J2-1883:
---------------------------------------
I add some further thinking about what the API of the "PreciseClock" interface
could be, and especially about that new timestamp data structure, and I'm not
satisfied with the idea of a new data structure:
- we want it to be mutable so that the PreciseClock can populate it, but we
want it to be immutable when returned by the LogEvent API
- having an "immutable precise timestamp" interface seems pretty odd, since
Instant already exists in Java 8. I think that it is cleaner to have 2 getters
for the detailed information (second from epoch + nano in seconds, or milli
from epoch + nano in millis), and later when Log4J2 will be compiled with java
8+ add an Instant getter (that will not be allocation free, but offers an
easier API for users not interested in the allocation free behaviors)
- performance-wise, the current LogEvent implementations uses 8 bytes for a
millisecond timestamp. Adding another int field for better precision is 16
bytes cheaper than replacing the current long field with an "Instant-like" data
structure and offers better memory locality by avoiding another indirection
,
So, how to design that precise clock without an additional data structure ?
That's exactly what is done inside the JDK9 implementation of SystemClock : the
internal VM class has a method getNanoTimeAdjustment() which takes a long
parameter representing some seconds from epoch not too far from current time
(and this time reference is cached in a static field of the SystemClock class)
and returns the nanoseconds from this reference timestamp (or -1 if current
time is more than 2^32 seconds away from the reference).
I think that such a design for the PreciseClock interface can be good :
- it uses only native types for parameters and return values, so implementors
are free to provide allocation-free implementations (and even a pure java
implementation might be allocation free with escape analysis)
- It is easy to make a standard Clock implement the new PreciseClock method.
Indeed, if we were using Java 8 there will be probably no need to a new
Interface, the getNanoTimeAdjustment() method would be a new default method in
the clock API.
I will try to provide a proof of concept using of such an API in my github repo
if you are interested in that design.
> Timestamp does not seem to support microseconds level
> -----------------------------------------------------
>
> Key: LOG4J2-1883
> URL: https://issues.apache.org/jira/browse/LOG4J2-1883
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Environment: Linux with any JDK including JDK1.8
> Reporter: Madhava Dass
> Priority: Critical
>
> Used log4j and 'log4j2.xml' to configure timestamp format as:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <Configuration status="WARN">
> <Appenders>
> <Console name="Console" target="SYSTEM_OUT">
> <PatternLayout
> pattern="[%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}{UTC}][%level][%logger{36}]:%msg%n"/>
> </Console>
> </Appenders>
> <Loggers>
> <Root level="DEBUG">
> <AppenderRef ref="Console"/>
> </Root>
> </Loggers>
> </Configuration>
> {code}
> This pattern produces the time stamp as:
> {code}
> [2017-03-29T13:55:28.363000][null]:[Thread-1]: - <message>
> {code}
> The desired output is:
> {code}
> [2017-03-29T13:55:28.363701-07:00][null]:[Thread-1]: - <message>
> {code}
> Different versions of JDKs were tried including JDK 1.8. It does not seem to
> make any difference in the outcome.
> Is there a way to get the desired time stamp through pattern matching
> configuration in the '*.xml' file?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
