[
https://issues.apache.org/jira/browse/LOG4J2-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632322#comment-14632322
]
Remko Popma commented on LOG4J2-1074:
-------------------------------------
I'm reasonably happy with the last option. The resulting design is as follows:
* Introduce a new {{NanoTimePatternConverter}}. If a pattern layout contains
conversion pattern {{%N}} or {{%nano}} an instance of NanoTimePatternConverter
is included in the layout. This converter includes nanosecond timestamps in the
log output (in String.valueOf(long) format).
* Introduce a new {{NanoClockFactory}} to create {{NanoClock}} instances. By
default this factory creates {{DummyNanoClock}} instances which always return
a fixed value, but it can be switched to create {{SystemNanoTime}} instances
which call {{System.nanoTime()}}.
* When a layout is parsed, {{PatternParser}} toggles the {{NanoClockFactory}}
to the correct mode depending on whether the list of {{PatternConverter}} s
contains a NanoTimePatternConverter or not.
* {{Log4jLogEvent}} has a {{NanoClock}} and populates its nanoTime field in its
constructor (similarly to the way it uses its {{Clock}} to populate its
timeMillis field). The {{nanoTime}} field is final in Log4jLogEvent.
* {{RingBufferLogEvent}} s are pre-allocated (as per the Disruptor design) and
their values are populated by {{AsyncLogger}}. Hence AsyncLogger also has a
NanoClock (just like it has a Clock for the milliseconds timestamp).
* Initially both Log4jLogEvent and AsyncLogger have a {{DummyNanoClock}}.
* When a new configuration is installed, {{LoggerContext}} asks the
{{NanoClockFactory}} to create a new NanoClock instance and tells
{{Log4jLogEvent}} and {{AsyncLogger}} to use this NanoClock from now on.
This has slightly looser coupling (one level of indirection via the nano clock
factory). Still not perfect since the LoggerContext is hard-coded to only
change the NanoClock for Log4jLogEvent and AsyncLogger. On the other hand,
LoggerContext already has the responsibility of re-registering MBeans after a
reconfiguration, and I felt this new task is consistent with that. One
advantage of this design is that it makes the minimum number of changes to
public interfaces (no changes to LogEventFactory or Configuration and no change
to the public Log4jLogEvent constructors). I hope this will make things easier
in case we ever come up with a better design later on.
Implementation is done. Now working on documentation and unit tests.
> Add a logformat token for nanotime
> ----------------------------------
>
> Key: LOG4J2-1074
> URL: https://issues.apache.org/jira/browse/LOG4J2-1074
> Project: Log4j 2
> Issue Type: New Feature
> Reporter: Will Hains
> Assignee: Remko Popma
>
> Add a token in the log format specifier to output the current value of
> {{System.nanotime()}}.
> We are currently adding the nanotime value to our log messages manually,
> which we find very useful for troubleshooting unexpected latency, and as a
> quick-and-dirty data source to feed into performance analysis tools.
> It would be very nice if Log4j could do this for us. It would also be nice to
> have this in the log format specified, so we can turn it on/off at runtime by
> editing the Log4j config file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
