-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite date & time formatting #3121
base: 2.x
Are you sure you want to change the base?
Conversation
…elector. (#3092) Fixes #3078 Co-authored-by: Martin Dorey <[email protected]>
Fixes the names of configuration properties introduced after `2.10.0` to always use the normalized form. Fixes #3079
This commit: - Removes support for the outdated [Jansi 1.x](http://fusesource.github.io/jansi/) version in `Console` appender. - Rewrites `JAnsiTextRenderer`, use in the `%m{ansi}` and `%ex{ansi}` pattern converters to use our internal ANSI support instead of Jansi. Fixes #1736.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't really need DTF to print sub-day patterns (hours, minutes, seconds, etc.).
@ppkarwasz, what do you mean? If the pattern is, say, yyyy-MM-dd HH:mm:ss.SSS
, we cache yyyy-MM-dd HH:mm:
part and update it once per minute. I think this once-per-minute cost is negligible in a real-world setup.
Are you sure
DTF
is garbage-free for these patterns? Can you add a test for it?
DTF is not garbage-free – no matter which method of DTF you use. Hence, neither our InstantPatternDynamicFormatter
is garbage-free.
the
PatternSequence
s can actually be pre-computed, which would improve the time to generate the formatters.
Agreed, but I doubt if this additional complexity brings any practical benefit. Even my JMH tests run for 30 seconds, that is, they don't even encounter any sequencing operation.
Allow me to remind that my aim with this PR is not to implement the fastest instant formatter on top of DTF, but implement the simplest one with acceptable performance. FixedDF
and FastDF
were enough of a lesson for what happens with unsolicited complexity.
log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/DatePatternConverter.java
Outdated
Show resolved
Hide resolved
import org.apache.logging.log4j.core.time.MutableInstant; | ||
import org.apache.logging.log4j.core.util.internal.instant.InstantFormatter; | ||
import org.apache.logging.log4j.core.util.internal.instant.InstantNumberFormatter; | ||
import org.apache.logging.log4j.core.util.internal.instant.InstantPatternFormatter; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using an internal Log4j Core package in JSON Template Layout poses an encapsulation problem:
- JPMS needs an
@ExportTo
annotation. - OSGi needs the package to be exported to anyone.
Since we clearly want to leave the minimal possible API cross-section to users and considering that o.a.l.l.core.time.InstantFormatter
is already present, might I suggest to:
- move
InstantFormatter
too.a.l.l.core.time.InstantFormatter
(oro.a.l.l.core.time.spi.InstantFormatter
to give more the impression it is not meant to be used by users). - add a
newInstance(String pattern, Locale locale, TimeZone timeZone)
static method that currently will only returno.a.l.l.core.time.spi.internal
implementations, but (if users request it) can be adapted in the future to use plugins/ServiceLoader
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OSGi needs the package to be exported to anyone.
Isn't there any other way for OSGi? (Yes, I don't want to open up the new package & classes.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC, when the subject of exports ... to
came out on dev@logging
(or maybe the PMC meeting) the consensus was that we should either export a package to all users or don't export it at all.
As I stated above, we only need to put InstantFormatter
in an exportable package. If the package has spi
in it, users will know that it only should be used by Log4j Plugin implementors.
In accordance with this
dev@
discussion, these changesFixedDateTime
andFastDateTime
InstantFormatter
contractInstantNumberFormatter
for epoch-related number-emitting formatting operationsInstantPatternNumber
contract for formatting based on a specified date & time patterInstantPatternThreadLocalCachedFormatter
which wraps anyInstantPatternNumber
and caches its values in aThreadLocal
for reusageInstantPatternDynamicFormatter
that uses Java'sDateTimeFormatter
under the hood such that the pattern is analyzed and parts that require a precision lower than or equal to minute are precomputed, cached, and updated per minute. That is,DateTimeFormatter
is effectively only used for sub-minute parts, e.g.,ss.SSS
.InstantPatternDynamicFormatter
internalsFor instance, given the pattern
yyyy-MM-dd'T'HH:mm:ss.SSSX
, the generated formatter willMM
is of month precision)yyyy-MM-dd'T'HH:mm:
andX
) and cache itss.SSS
)GC implications
Since
DateTimeFormatter
is not garbage-free, neither the newInstantPatternDynamicFormatter
is.Performance implications
JDK: Azul Zulu
17.0.12
OS: GNU/Linux
Date & time pattern:
yyyy-MM-dd'T'HH:mm:ss.SSS
InstantPatternFormatterBenchmark
This benchmark stresses instant formatting efficiency. 1000 instants are formatted per operation.
Interpretation: When used in isolation,
FixedDF
yields a throughput of ~8x compared toInstantPF
.InstantPatternFormatterImpactBenchmark
This benchmark stresses instant formatting efficiency when combined with
PatternLayout
configured with the[%t] %p %-40.40c{1.} %notEmpty{%x }- %m%n
pattern. 1000LogEvent
s are formatted per operation.Using full log events (incl. exception, MDC & NDC):
Interpretation: When
LogEvent
contains an exception, instant formatting efficiency becomes irrelevant.Using lite log events:
Interpretation: When
LogEvent
doesn't contain an exception, MDC/NDC field, etc.,FixedDF
yields a throughput of ~2x compared toInstantPF
.Bug implications
Fixes #2943.