[
https://issues.apache.org/jira/browse/LOG4J2-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974930#comment-15974930
]
Anthony Maire commented on LOG4J2-1883:
---------------------------------------
Hi
Having this microsecond precision will become a key feature for a logging
framework in financial services, since because of the european MiFID II
regulation, some trading systems will have to timestamp events with resolution
of 100µs or better as of 2018. As far as I know, logging with microsecond
resolution is currently provided by j.u.l with Java 9 only. It will be nice if
it can be integrated in Log4J (and I can dedicate some time to work on this, I
just need to have a better idea of what a good solution can be so it has a
chance to be merged)
As Ralph said earlier, the issue is that there is no standard way to have such
a precise timestamp before Java 9 :
- System.nanotime() is not a timestamp
- java.time.Clock$SystemClock (used by Instant.now() and LocalDateTime.now())
is implemented with System.currentTimeMillis() in Java 8 although the data
structure can transport a precise timestamp
In Java 9, SystemClock has the underlying OS precision, cf
https://bugs.openjdk.java.net/browse/JDK-8068730
If an application needs such precise timestamping and cannot afford to migrate
to Java 9, it has no other choice than using JNI/JNA to get the timestamp
directly from the OS.
To have the µs resolution support in Log4J2, there will be a need to let the
application inject a kind of "time source" (as I assume that this necessary
native interface will not be part of Log4J2).
As first sight, java.time package directly has 2 major issues :
- It will not be usable until Log4J2 is compiled with java 8 (I don't know if
there is any plan to drop Java 7 support in a near future, for exemple when
java 9 will be released ?)
- It will create some Instant instances (although they are maybe eliminated by
escape analysis ?) and break the 0-allocation effort that have been made.
Unfortunately, in the Clock API, there is only an allocation-free method for
milliseconds, but nothing for lower resolution :( So the call should be made
only if we know that a pattern will use this information.
But as soon the application is running on a Java 9 JVM, it will have
microsecond resolution for free without any code change since the Clock API
will not change. And for Java 8 application, they can still provide a custom
JNA based java.time.Clock
If we have to stick to java 7 for now, I wonder if something similar that
LOG4J2-1074 can be done for this feature (or even re-use the nanotime field
that have been created for it?), which can be done without using the java.time
package ...
> 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)
