Re: [PR] Remove ineffective tests (logging-log4j2)
vy commented on PR #2209: URL: https://github.com/apache/logging-log4j2/pull/2209#issuecomment-1905476275 > What criteria was used to determine that the tests were "ineffective"? Anything with "perf" in the name was just deemed ineffective? @rgoers, removed tests either were disabled long ago (causing compilation time waste) or contained no assertions (causing compilation + testing time waste). I tried saving whatever I can and removed the rest of such _ineffective_ tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Create an alternative async logger implementation using JCTools (logging-log4j2)
rgoers commented on issue #2220: URL: https://github.com/apache/logging-log4j2/issues/2220#issuecomment-1905367158 AsyncLogger will improve the perceived performance of the application by giving control back to it sooner than an AsyncAppender, and if you have filters and more than one appender that can make a difference. Note that it will NOT improve the actual speed of logging. While I do not like the idea of removing AsyncLogger support I am in favor of moving it to a log4j-async module, assuming that can be done. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Remove ineffective tests (logging-log4j2)
rgoers commented on PR #2209: URL: https://github.com/apache/logging-log4j2/pull/2209#issuecomment-1905335515 What criteria was used to determine that the tests were "ineffective"? Anything with "perf" in the name was just deemed ineffective? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Improve AsyncAppender throughput [logging-log4cxx]
swebb2066 commented on PR #335: URL: https://github.com/apache/logging-log4cxx/pull/335#issuecomment-1905086551 Relevant Ubuntu gcc 9 benchmarks improve from: | Benchmark | Time | CPU | Iterations | | | -- | | --- | | Async, int value using MessageBuffer, pattern: %m%n | 605 ns | 605 ns | 1171481 | | Async, int value using MessageBuffer, pattern: %m%n/threads:16 | 997 ns | 8010 ns | 89648 | to: | Benchmark | Time | CPU | Iterations | | | | --- | | | Async, int value using MessageBuffer, pattern: %m%n | 583 ns | 583 ns | 1249185 | | Async, int value using MessageBuffer, pattern: %m%n/threads:16 | 978 ns | 7950 ns | 88320 | -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Improve AsyncAppender throughput [logging-log4cxx]
swebb2066 opened a new pull request, #335: URL: https://github.com/apache/logging-log4cxx/pull/335 This PR aims to reduce synchronization contention when logging through AsynicAppender. Relevant Windows benchmarks improve from: | Benchmark | Time | CPU | Iterations | | - | - | - | - | | Logging int value using MessageBuffer, pattern: %m%n | 1666 ns | 739 ns | 112 | | Logging int value using MessageBuffer, pattern: %m%n/threads:4 | 710 ns | 1090 ns | 573440 | | Logging int value using MessageBuffer, pattern: [%d] %m%n | 1727 ns | 816 ns | 746667 | | Logging int value using MessageBuffer, pattern: [%d] [%c] [%p] %m%n | 1686 ns | 688 ns | 100 | | Logging int value using FMT, pattern: %m%n | 730 ns | 353 ns | 2036364 | | Logging int value using FMT, pattern: %m%n/threads:4 | 504 ns | 1004 ns | 995556 | | Async, int value using MessageBuffer, pattern: %m%n | 1719 ns | 673 ns | 1115023 | | Async, int value using MessageBuffer, pattern: %m%n/threads:4 | 789 ns | 1360 ns | 448000 | to: | Benchmark | Time | CPU | Iterations | | | | - | --- | | Logging int value using MessageBuffer, pattern: %m%n | 2181 ns | 507 ns | 1079054 | | Logging int value using MessageBuffer, pattern: %m%n/threads:4 | 727 ns | 1591 ns | 716800 | | Logging int value using MessageBuffer, pattern: [%d] %m%n | 1898 ns | 1046 ns | 746667 | | Logging int value using MessageBuffer, pattern: [%d] [%c] [%p] %m%n | 1672 ns | 858 ns | 746667 | | Logging int value using FMT, pattern: %m%n | 747 ns | 474 ns | 112 | | Logging int value using FMT, pattern: %m%n/threads:4 | 454 ns | 929 ns | 689232 | | Async, int value using MessageBuffer, pattern: %m%n | 1654 ns | 879 ns | 112 | | Async, int value using MessageBuffer, pattern: %m%n/threads:4 | 671 ns | 1484 ns | 40 | -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Reduce logging overhead [logging-log4cxx]
swebb2066 merged PR #333: URL: https://github.com/apache/logging-log4cxx/pull/333 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Remove JMX support (logging-log4j2)
ppkarwasz opened a new pull request, #2228: URL: https://github.com/apache/logging-log4j2/pull/2228 As partial solution to #1344, this PR drop JMX support and replaces the usage of `RingBufferAdmin` in tests with a direct access to the `RingBuffer`. ## Motivation JMX is an old monitoring technology, which less and less used today. Given its inherent insecurity, we should evaluate if JMX support should even be part of Log4j Core. Our JMX support code is the main obstacle to the separation of `AsyncLogger` and related code into its own artifact. IMHO we should drop JMX support in 3.0.x and evaluate if such a technology should be added again in 3.1.x. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Add security threat model to docs (logging-log4j2)
ppkarwasz commented on PR #2219: URL: https://github.com/apache/logging-log4j2/pull/2219#issuecomment-1904814620 @raboof, Could you take a look at this? It looks fine from our perspective. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Issue with logs being stopped getting generated at midnight while using date based rollover strategy in log4j2 (logging-log4j2)
ppkarwasz commented on issue #2010:
URL:
https://github.com/apache/logging-log4j2/issues/2010#issuecomment-1904588151
@snaralasetty,
In the sample of your logs I can not find **any** message that matches the
`%d:%-7p:%t: %-60m [%X{AppUserId}]: [%X{TenantId}]: %-25c{1}%n` pattern
configured. Are you sure these are generated by Log4j Core?
If multiple logging backends are rotating the same files the results are
unpredictable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [I] [MS8] Branch `main` overhaul #3 (logging-log4j2)
ppkarwasz commented on issue #2163: URL: https://github.com/apache/logging-log4j2/issues/2163#issuecomment-1904575744 While working on #2227 I checked that no regressions are present in the `o.a.l.l.core.async` package in the `main` branch. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Add security threat model to docs (logging-log4j2)
jvz commented on code in PR #2219:
URL: https://github.com/apache/logging-log4j2/pull/2219#discussion_r1462240868
##
src/site/asciidoc/security.adoc:
##
@@ -46,6 +46,89 @@ If you have encountered an unlisted security vulnerability
or other unexpected b
The threat model that Log4j uses considers configuration files as safe input
controlled by the programmer; **potential vulnerabilities that require the
ability to modify a configuration are not considered vulnerabilities** as the
required access to do so implies the attacker can execute arbitrary code.
+[#model]
+== Threat Model
+
+Log4j is a low level library where configuration inputs and the classpath are
expected to be controlled by the programmer.
+Configurations have the ability to execute arbitrary code through custom
plugins.
+While specific Log4j plugins (such as a JNDI lookup) may use constraint
validators or conditionals to require additional settings to opt in to
functionality, this is not universally required by custom plugins.
+Specific security considerations involved in our threat model are detailed
below.
+
+=== Parameterized Logging
+
+When using a log message containing template parameters like `{}`, only the
format string is evaluated for parameters to be substituted.
+The message parameters themselves are not evaluated for parameters; they are
only included in the format string corresponding to their template position.
+The conversion of message parameters into a string is done on-demand depending
on the layout being used.
+When structure-preserving transformations of log message data are required,
the `Message` API should be used for logging structured data.
+
+=== Unstructured Logging
+
+When using an unstructured layout such as `PatternLayout`, no guarantees can
be made about the output format.
+This layout is mainly useful for development purposes and should not be relied
on in production applications.
+For example, if a log message contains new lines, these are not escaped or
encoded specially unless the configured pattern uses the
`%encode{pattern}{CRLF}` wrapper pattern converter (which will encode a
carriage return as the string `\r` and a line feed as the string `\n`) or some
other `%encode` option.
Review Comment:
Added
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Add security threat model to docs (logging-log4j2)
jvz commented on code in PR #2219:
URL: https://github.com/apache/logging-log4j2/pull/2219#discussion_r1462233204
##
src/site/asciidoc/security.adoc:
##
@@ -46,6 +46,89 @@ If you have encountered an unlisted security vulnerability
or other unexpected b
The threat model that Log4j uses considers configuration files as safe input
controlled by the programmer; **potential vulnerabilities that require the
ability to modify a configuration are not considered vulnerabilities** as the
required access to do so implies the attacker can execute arbitrary code.
+[#model]
+== Threat Model
+
+Log4j is a low level library where configuration inputs and the classpath are
expected to be controlled by the programmer.
+Configurations have the ability to execute arbitrary code through custom
plugins.
+While specific Log4j plugins (such as a JNDI lookup) may use constraint
validators or conditionals to require additional settings to opt in to
functionality, this is not universally required by custom plugins.
+Specific security considerations involved in our threat model are detailed
below.
+
+=== Parameterized Logging
+
+When using a log message containing template parameters like `{}`, only the
format string is evaluated for parameters to be substituted.
+The message parameters themselves are not evaluated for parameters; they are
only included in the format string corresponding to their template position.
+The conversion of message parameters into a string is done on-demand depending
on the layout being used.
+When structure-preserving transformations of log message data are required,
the `Message` API should be used for logging structured data.
+
+=== Unstructured Logging
+
+When using an unstructured layout such as `PatternLayout`, no guarantees can
be made about the output format.
+This layout is mainly useful for development purposes and should not be relied
on in production applications.
+For example, if a log message contains new lines, these are not escaped or
encoded specially unless the configured pattern uses the
`%encode{pattern}{CRLF}` wrapper pattern converter (which will encode a
carriage return as the string `\r` and a line feed as the string `\n`) or some
other `%encode` option.
+Similarly, other encoding options are available for other formats, but pattern
layouts cannot make assumptions about the entire output.
+As such, when using unstructured layouts, no user-controlled input should be
included in logs.
+It is strongly recommended that a structured layout is used instead for these
situations.
+Note that `StrLookup` plugins (those referenced by `${...}` templates in
configuration files) that contain user-provided input should not be referenced
by a pattern layout.
+
+=== Structured Logging
+
+When using a structured layout (most layouts besides pattern layout), log
messages are encoded according to various output formats.
+These safely encode the various fields included in a log message.
+For example, the JSON template layout can be configured to output log messages
in various JSON structures where all log data is properly encoded into safely
parseable JSON.
+This is the recommended mode of operation for use with log parsing and log
collection tools that rely on log files or arbitrary output streams.
+
+=== Code Signing
+
+Log4j artifacts are all signed using PGP using a key from the Logging Services
PMC https://downloads.apache.org/logging/KEYS[KEYS file].
+Information on how to verify releases signed with PGP is
https://httpd.apache.org/dev/verification.html[documented here].
+Individual jar files are not signed using `jarsigner` (only PGP), and the
Log4j plugin system does not rely on signed jars for validation (unlike the
Java cryptography APIs for example).
+Thus, PGP signatures should be validated in your build process.
+
+=== Java Security Manager
+
+Log4j no longer supports running in or using a custom `SecurityManager`.
+This Java feature has been deprecated for removal in Java 21.
+Previous versions of Log4j 2.x include partial support for running with a
security manager.
+
+=== Log Masking
+
+Log4j, like any other generic logging library, cannot generically support log
masking of sensitive data.
+While custom plugins may be developed to attempt to mask various regular
expressions (such as a string that looks like a credit card number), the
general problem of log masking is equivalent to the halting problem in computer
science where sensitive data can always be obfuscated in such a way as to avoid
detection by log masking.
+As such, it is the responsibility of the developer to properly demarcate
sensitive data such that it can be consistently masked by log masking plugins.
+This sort of use case should make use of the `Message` API for better control
over the output of such data.
+
+=== Availability
+
+Log4j goes to great lengths to minimize performance overhead along with
options for minimizing latency or maximizing
Re: [PR] Add security threat model to docs (logging-log4j2)
jvz commented on code in PR #2219:
URL: https://github.com/apache/logging-log4j2/pull/2219#discussion_r1462229803
##
src/site/asciidoc/security.adoc:
##
@@ -46,6 +46,89 @@ If you have encountered an unlisted security vulnerability
or other unexpected b
The threat model that Log4j uses considers configuration files as safe input
controlled by the programmer; **potential vulnerabilities that require the
ability to modify a configuration are not considered vulnerabilities** as the
required access to do so implies the attacker can execute arbitrary code.
+[#model]
+== Threat Model
+
+Log4j is a low level library where configuration inputs and the classpath are
expected to be controlled by the programmer.
+Configurations have the ability to execute arbitrary code through custom
plugins.
+While specific Log4j plugins (such as a JNDI lookup) may use constraint
validators or conditionals to require additional settings to opt in to
functionality, this is not universally required by custom plugins.
+Specific security considerations involved in our threat model are detailed
below.
+
+=== Parameterized Logging
+
+When using a log message containing template parameters like `{}`, only the
format string is evaluated for parameters to be substituted.
+The message parameters themselves are not evaluated for parameters; they are
only included in the format string corresponding to their template position.
+The conversion of message parameters into a string is done on-demand depending
on the layout being used.
+When structure-preserving transformations of log message data are required,
the `Message` API should be used for logging structured data.
Review Comment:
It's both. Since the APIs for specifying non-string values into the thread
context is kind of awkward, and it can be wasteful to store things there which
are only relevant for a single log message, it's useful to use something like a
`MapMessage`, and yes, you need to combine that with something like JTL to
preserve the structure of the message.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [I] Create an alternative async logger implementation using JCTools (logging-log4j2)
jvz commented on issue #2220: URL: https://github.com/apache/logging-log4j2/issues/2220#issuecomment-1904487452 I like where this conversation is going so far! Do either of you have advice on performance measurements here? While I can certainly implement things according to recommendations here, I'm not very familiar with the benchmarking process. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Issue with logs being stopped getting generated at midnight while using date based rollover strategy in log4j2 (logging-log4j2)
snaralasetty commented on issue #2010: URL: https://github.com/apache/logging-log4j2/issues/2010#issuecomment-1904309340 Any further update on this Piotr P. Karwasz? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Simplify async logger in `main` (logging-log4j2)
ppkarwasz opened a new pull request, #2227: URL: https://github.com/apache/logging-log4j2/pull/2227 Due to the introduction of `Recycler` in `main` and related changes, many async loggers can be simplified: * no thread name caching is required, * in many methods we can use `ReusableLogEvent` instead of concrete classes, * many casts from `ReadOnlyStringMap` to `StringMap` are not necessary. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Issue 1501: increase default StatusLogger level to warn (logging-log4j2)
vy commented on PR #1592: URL: https://github.com/apache/logging-log4j2/pull/1592#issuecomment-1904116163 @lukaszspyra, I am sorry for the delay. There were more pressing issues. As a part of our ongoing effort to clean up the `log4j-api` in `2.x`, we are re-visiting the idea of decreasing the default `StatusLogger` level from `ERROR` to `WARN`. PMC is mostly concerned about the noise this will create for existing users. Once the default level is set to `WARN`, some warnings will start getting displayed on unrecognized/ignored properties. This is good. OTOH, there will also appear some not much useful warnings, e.g., `The bufferSize is set to ... but bufferedIo is false`. **Would you be interested in fixing these (e.g., lowering the level of such messages to `INFO` or conditionally enabling them)** and adding that your PR? I believe we (@ppkarwasz?) can provide assistance for such an effort. PMC needs to be convinced anyway. But if their _"logging noise"_ concerns are addressed, I don't expect a blocker from that direction. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Deprecate `StatusConsoleListener` filters (logging-log4j2)
vy merged PR #2226: URL: https://github.com/apache/logging-log4j2/pull/2226 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Issue 1501: increase default StatusLogger level to warn (logging-log4j2)
ppkarwasz commented on PR #1592: URL: https://github.com/apache/logging-log4j2/pull/1592#issuecomment-1903912059 @lukaszspyra, Sorry for the delayed answer. Your PR looks good to me, if the default status logger level of `ERROR` can not be changed. Personally I don't agree that `WARN` messages should be hidden by default and I prefer your original version, but there is no consensus on this matter in the PMC. @vy what do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Deprecate `StatusConsoleListener` filters (logging-log4j2)
vy opened a new pull request, #2226: URL: https://github.com/apache/logging-log4j2/pull/2226 This PR deprecates the configuration attribute `verbose` (i.e., `
Re: [PR] Bump io.netty:netty-bom from 4.1.105.Final to 4.1.106.Final (logging-log4j2)
github-actions[bot] merged PR #2224: URL: https://github.com/apache/logging-log4j2/pull/2224 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump spring-boot.version from 3.2.1 to 3.2.2 (logging-log4j2)
github-actions[bot] merged PR #: URL: https://github.com/apache/logging-log4j2/pull/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump io.netty:netty-bom from 4.1.105.Final to 4.1.106.Final (logging-log4j2)
github-actions[bot] merged PR #2225: URL: https://github.com/apache/logging-log4j2/pull/2225 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Create an alternative async logger implementation using JCTools (logging-log4j2)
franz1981 commented on issue #2220: URL: https://github.com/apache/logging-log4j2/issues/2220#issuecomment-1903661785 Hi! Entering in the discussion, because I'm one of the developers of JCTools (@nitsanw is both and the author!) I've always considered a more preferred approach to accumulate the logevents locally (if is not a virtual thread, in a thread local's buffer) - and have a flusher thread which drain at intervals. To backpressure, you can put some boundaries to the thread local capacity, and await/throttle if there's isn't any room. This approach (which can still use a unbounded queue, without signaling to poller/flush) guarantee that: - an almost idle poller/flusher, doesn't have to awaken reducing the overhead on the logging/application threads (which doesn't compete nor spend any cycles on signaling) - allow the flusher to tune its own flushing frequency based on the estimated size of the flushing queue or just the estimated submission rate -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Question: using AsyncAppender [logging-log4cxx]
atari83 closed issue #332: Question: using AsyncAppender URL: https://github.com/apache/logging-log4cxx/issues/332 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Question: using AsyncAppender [logging-log4cxx]
atari83 commented on issue #332: URL: https://github.com/apache/logging-log4cxx/issues/332#issuecomment-1903588627 Got it ! Thank you Stephen, Robert for the responses :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] Create an alternative async logger implementation using JCTools (logging-log4j2)
ppkarwasz commented on issue #2220: URL: https://github.com/apache/logging-log4j2/issues/2220#issuecomment-1903549607 @nitsanw, You are probably right: the main difference between `AsyncLogger`, `AsyncLoggerConfig` and `AsyncAppender` is that the first two have **full control** over the lifecycle of _mutable_ log events, so they can modify log events (e.g. swap parameters between events) without breaking other components. The further down we go in the logging pipeline, the harder it becomes to perform such tricks. The logic of `AsyncLogger` is almost trivial (it breaks the log event by moving its components to the disruptor and resets the event); the logic of `AsyncLoggerConfig` is more complex (it must perform all synchronous logging before breaking the log event); `AsyncAppender` doesn't even try to deal with mutable events and takes a snapshot of the current event. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
