Re: [PR] Upgrade CI dependencies [logging-log4cxx]
swebb2066 merged PR #334: URL: https://github.com/apache/logging-log4cxx/pull/334 -- 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] Upgrade CI dependencies [logging-log4cxx]
swebb2066 opened a new pull request, #334: URL: https://github.com/apache/logging-log4cxx/pull/334 (no comment) -- 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 commented on PR #333: URL: https://github.com/apache/logging-log4cxx/pull/333#issuecomment-1903011007 On Ubuntu gcc 9, benchmarks improve from: | Benchmark | Time | CPU | Iterations | | | - | -- | --- | | Testing disabled logging request | 0.474 ns | 0.474 ns | 10 | | Testing disabled logging request/threads:16 | 0.093 ns | 1.01 ns | 681895600 | | Logging 5 char string using MessageBuffer, pattern: %m%n | 413 ns | 413 ns | 1700177 | | Logging 5 char string using MessageBuffer, pattern: %m%n/threads:16 | 977 ns | 7913 ns | 91360 | | Logging 49 char string using MessageBuffer, pattern: %m%n | 435 ns | 435 ns | 1606003 | | Logging 49 char string using MessageBuffer, pattern: %m%n/threads:16 | 980 ns | 7856 ns | 92928 | | Logging int value using MessageBuffer, pattern: %m%n | 608 ns | 607 ns | 1198654 | | Logging int value using MessageBuffer, pattern: %m%n/threads:16 | 1000 ns | 8050 ns | 88992 | | Logging int+float using MessageBuffer, pattern: %m%n | 1068 ns | 1068 ns | 656795 | | Logging int+float using MessageBuffer, pattern: %m%n/threads:16 | 946 ns | 7671 ns | 86656 | | Logging int value using MessageBuffer, pattern: [%d] %m%n | 633 ns | 633 ns | 1106264 | | Logging int value using MessageBuffer, pattern: [%d] [%c] [%p] %m%n | 631 ns | 631 ns | 1112696 | | Logging 49 char string using FMT, pattern: %m%n | 404 ns | 404 ns | 1728028 | | Logging 49 char string using FMT, pattern: %m%n/threads:16 | 982 ns | 7914 ns | 91152 | | Logging int value using FMT, pattern: %m%n | 429 ns | 429 ns | 1629010 | | Logging int value using FMT, pattern: %m%n/threads:16 | 982 ns | 7928 ns | 90304 | | Logging int+float using FMT, pattern: %m%n | 623 ns | 623 ns | 1124386 | | Logging int+float using FMT, pattern: %m%n/threads:16 | 984 ns | 7928 ns | 88768 | | Async, int value using MessageBuffer, pattern: %m%n | 605 ns | 605 ns | 1206157 | | Async, int value using MessageBuffer, pattern: %m%n/threads:16 | 1007 ns | 8162 ns | 89472 | to: | Benchmark | Time | CPU | Iterations | | | - | | --- | | Testing disabled logging request | 0.474 ns | 0.474 ns | 10 | | Testing disabled logging request/threads:16 | 0.094 ns | 1.01 ns | 720825520 | | Logging 5 char string using MessageBuffer, pattern: %m%n | 304 ns | 304 ns | 2129199 | | Logging 5 char string using MessageBuffer, pattern: %m%n/threads:16 | 440 ns | 3565 ns | 208944 | | Logging 49 char string using MessageBuffer, pattern: %m%n | 328 ns | 328 ns | 2124087 | | Logging 49 char string using MessageBuffer, pattern: %m%n/threads:16 | 443 ns | 3589 ns | 196688 | | Logging int value using MessageBuffer, pattern: %m%n | 503 ns | 503 ns | 1457723 | | Logging int value using MessageBuffer, pattern: %m%n/threads:16 | 456 ns | 3710 ns | 172304 | | Logging int+float using MessageBuffer, pattern: %m%n | 951 ns | 951 ns | 731160 | | Logging int+float using MessageBuffer, pattern: %m%n/threads:16 | 560 ns | 4571 ns | 174688 | | Logging int value using MessageBuffer, pattern: [%d] %m%n | 574 ns | 574 ns | 1213959 | | Logging int value using MessageBuffer, pattern: [%d] [%c] [%p] %m%n | 575 ns | 575 ns | 1226639 | | Logging 49 char string using FMT, pattern: %m%n | 297 ns | 297 ns | 2352006 | | Logging 49 char string using FMT, pattern: %m%n/threads:16 | 440 ns | 3572 ns | 176944 | | Logging int value using FMT, pattern: %m%n | 321 ns | 321 ns | 2179192 | | Logging int value using FMT, pattern: %m%n/threads:16 | 438 ns | 3569 ns | 210704 | | Logging int+float using FMT, pattern: %m%n | 463 ns | 463 ns | 1511290 | | Logging int+float using FMT, pattern: %m%n/threads:16 | 377 ns | 3102 ns | 194976 | | Async, int value using MessageBuffer, pattern: %m%n | 501 ns | 501 ns | 1466060 | | Async, int value using MessageBuffer, pattern: %m%n/threads:16 | 449 ns | 3664 ns | 168144 | -- 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] Reduce logging overhead [logging-log4cxx]
swebb2066 opened a new pull request, #333: URL: https://github.com/apache/logging-log4cxx/pull/333 Ths PR improves benchmarks (on Windows) from: | Benchmark | Time | CPU | Iterations | | --- | -- | -- | -- | | Testing disabled logging request | 2.70 ns | 0.391 ns | 10 | | Testing disabled logging request/threads:4 | 0.989 ns | 1.58 ns | 663703704 | | Logging 5 char string using MessageBuffer, pattern: %m%n | 678 ns | 258 ns | 2357895 | | Logging 5 char string using MessageBuffer, pattern: %m%n/threads:4 | 466 ns | 733 ns | 1258332 | | Logging 49 char string using MessageBuffer, pattern: %m%n | 780 ns | 305 ns | 1947826 | | Logging 49 char string using MessageBuffer, pattern: %m%n/threads:4 | 498 ns | 753 ns | 746668 | | Logging int value using MessageBuffer, pattern: %m%n | 1703 ns | 750 ns | 896000 | | Logging int value using MessageBuffer, pattern: %m%n/threads:4 | 697 ns | 1445 ns | 40 | | Logging int+float using MessageBuffer, pattern: %m%n | 3170 ns | 1151 ns | 746667 | | Logging int+float using MessageBuffer, pattern: %m%n/threads:4 | 1298 ns | 2668 ns | 298668 | | Logging int value using MessageBuffer, pattern: [%d] %m%n | 1703 ns | 771 ns | 1115023 | | Logging int value using MessageBuffer, pattern: [%d] [%c] [%p] %m%n | 1710 ns | 774 ns | 746667 | | Logging 49 char string using FMT, pattern: %m%n | 765 ns | 356 ns | 2635294 | | Logging 49 char string using FMT, pattern: %m%n/threads:4 | 442 ns | 867 ns | 128 | | Logging int value using FMT, pattern: %m%n | 741 ns | 364 ns | 2357895 | | Logging int value using FMT, pattern: %m%n/threads:4 | 475 ns | 596 ns | 943156 | | Logging int+float using FMT, pattern: %m%n | 1096 ns | 544 ns | 112 | | Logging int+float using FMT, pattern: %m%n/threads:4 | 501 ns | 997 ns | 814544 | | Async, int value using MessageBuffer, pattern: %m%n | 1712 ns | 837 ns | 896000 | to | Benchmark | Time | CPU | Iterations | | - | | --- | | | Testing disabled logging request | 2.56 ns | 0.438 ns | 10 | | Testing disabled logging request/threads:4 | 1.03 ns | 1.48 ns | 89600 | | Logging 5 char string using MessageBuffer, pattern: %m%n | 588 ns | 236 ns | 3446154 | | Logging 5 char string using MessageBuffer, pattern: %m%n/threads:4 | 328 ns | 488 ns | 1792000 | | Logging 49 char string using MessageBuffer, pattern: %m%n | 671 ns | 256 ns | 2986667 | | Logging 49 char string using MessageBuffer, pattern: %m%n/threads:4 | 357 ns | 537 ns | 128 | | Logging int value using MessageBuffer, pattern: %m%n | 1580 ns | 600 ns | 112 | | Logging int value using MessageBuffer, pattern: %m%n/threads:4 | 676 ns | 1334 ns | 597332 | | Logging int+float using MessageBuffer, pattern: %m%n | 3189 ns | 1172 ns | 64 | | Logging int+float using MessageBuffer, pattern: %m%n/threads:4 | 1333 ns | 2511 ns | 448000 | | Logging int value using MessageBuffer, pattern: [%d] %m%n | 1649 ns | 693 ns | 1194667 | | Logging int value using MessageBuffer, pattern: [%d] [%c] [%p] %m%n | 1581 ns | 628 ns | 896000 | | Logging 49 char string using FMT, pattern: %m%n | 674 ns | 300 ns | 224 | | Logging 49 char string using FMT, pattern: %m%n/threads:4 | 333 ns | 649 ns | 2986668 | | Logging int value using FMT, pattern: %m%n | 629 ns | 239 ns | 249 | | Logging int value using FMT, pattern: %m%n/threads:4 | 310 ns | 537 ns | 128 | | Logging int+float using FMT, pattern: %m%n | 945 ns | 386 ns | 1659259 | | Logging int+float using FMT, pattern: %m%n/threads:4 | 424 ns | 711 ns | 112 | | Async, int value using MessageBuffer, pattern: %m%n | 1590 ns | 719 ns | 100 | | Async, int value using MessageBuffer, pattern: %m%n/threads:4 | 653 ns | 1295 ns | 663704 | -- 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]
rm5248 commented on issue #332: URL: https://github.com/apache/logging-log4cxx/issues/332#issuecomment-1902818118 > > possible to call the DOMConfigurator::configure function multiple times in my program > > Yes. `DOMConfigurator::configure` is most usefully automatically called when you change the configuration file. To use this feature call `DOMConfigurator::configureAndWatch` Note that the `configureAndWatch` methods simply look every X number of seconds to see if the file has changed. You can also load the file as soon as it changes using some sort of platform-dependent mechanism(e.g. `inotify` on Linux). If you're using Qt, you can compile the Qt support for Log4cxx and use [`log4cxx::qt::configureFromFileAndWatch`](https://github.com/apache/logging-log4cxx/blob/cfcd2ab940dd654ea030c497cb6a7252f1034e1d/src/main/include/log4cxx-qt/configuration.h#L42) which does this for you. -- 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]
swebb2066 commented on issue #332: URL: https://github.com/apache/logging-log4cxx/issues/332#issuecomment-1902814172 > possible to call the DOMConfigurator::configure function multiple times in my program Yes. `DOMConfigurator::configure` is most usefully automatically called when you change the configuration file. Do use this feature call `DOMConfigurator::configureAndWatch` -- 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]
swebb2066 commented on issue #332: URL: https://github.com/apache/logging-log4cxx/issues/332#issuecomment-1902810015 > FileAppender works just fine. I was thinking how could I optimize it more. The default value of `BufferedIO` is false [documented here](https://logging.apache.org/log4cxx/latest_stable/classlog4cxx_1_1FileAppender.html#a0126112f63df5a5c5e8adfb72c091d64) . Configuring the `BufferedIO` of `FileAppender` to `true` greatly (by up to 10 times) increases output rate. > BufferSize (bounded-buffer) parameter for AsyncAppender The default value is 128 > could be a situation that some data get aborted when application exited. I believe `AsyncAppender` will write all events before your program exits (unless abnormally terminated). However, if your program adds events to `AsyncAppender` faster then the background thread can write and the buffer overflows, then logging events will be discarded. Be sure to set `BufferedIO` of `FileAppender` to `true` in the appender attached to `AsyncAppender`. -- 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
[I] Question: using AsyncAppender [logging-log4cxx]
atari83 opened a new issue, #332: URL: https://github.com/apache/logging-log4cxx/issues/332 Hello! So, I'm working on a program that produce about 100K rows of data per minute and approximately each row is about 2K. While using simple and straightforward `FileAppender` works just fine. I was thinking how could I optimize it more. Please help me to see if I understand it correctly: 1- Using AsyncAppender would potentially assist me to solve the write-operations blocking issues. 2- It is possible to configure the BufferSize (bounded-buffer) parameter in XML DOM. But then I dont know what is default value, or how should I calculate it based on my program context. 3- The FileAppender also exposes BufferedIO and BufferSize. Again, I dont know what is default behavior and If I need to use that or not (the calculation method..) 4- Based on the nature of AsyncAppender class (asynchronous-based operations), there could be a situation that some data get aborted when application exited. If thats correct, Is there anyway that let me enforce the AsyncAppender object to write down remaining data before program exited ? My last question is not related to Appenders, but I just wanted to know if it is possible to call the `DOMConfigurator::configure` function multiple times in my program ? I'm asking this, because lets say I'm using logging different logs for different log-levels. So, based on the configured value for in tags, I would actually let the program to generate the logs I'd expected to see. For now, every time I want to change the log-level I have to restart the program. I was thinking if it applicable to call the function to reload the xml file to change the log-level for example and without requiring program to get restart ? Thanks. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Adds lighter v3 `Logger` interface (PoC) (logging-log4j2)
ppkarwasz commented on PR #2215: URL: https://github.com/apache/logging-log4j2/pull/2215#issuecomment-1902786893 No, it might be relevant in the future, but right now I am closing this PR. -- 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] Adds lighter v3 `Logger` interface (PoC) (logging-log4j2)
ppkarwasz closed pull request #2215: Adds lighter v3 `Logger` interface (PoC) URL: https://github.com/apache/logging-log4j2/pull/2215 -- 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] Adds lighter v3 `Logger` interface (PoC) (logging-log4j2)
vy commented on PR #2215: URL: https://github.com/apache/logging-log4j2/pull/2215#issuecomment-1902763617 @ppkarwasz, given [we decided to use `log4j-api-2.x` in `main`](https://lists.apache.org/thread/gvk0to32c13xsfz0ytczfs506svx3hxm), is this PR still relevant for me to review? -- 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)
vy commented on code in PR #2219:
URL: https://github.com/apache/logging-log4j2/pull/2219#discussion_r1461110865
##
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)
vy commented on code in PR #2219:
URL: https://github.com/apache/logging-log4j2/pull/2219#discussion_r1461103299
##
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:
Shouldn't we rather have said the following instead?
```suggestion
When structure-preserving transformations of log message data are required,
layouts supporting this functionality (e.g., `JsonTemplateLayout`) should be
used.
```
##
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.
Review Comment:
```suggestion
It is strongly recommended that a structured layout (e.g.,
`JsonTemplateLayout`) is used instead for these situations.
```
##
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
Re: [PR] Clean up `log4j-spring-cloud-config-client` dependencies (logging-log4j2)
vy commented on PR #2166: URL: https://github.com/apache/logging-log4j2/pull/2166#issuecomment-1902746187 @ppkarwasz thank you so much for your effort and understanding in this PR. You also have done a great job by [introducing our agreement here as a general policy to the Log4j team](https://lists.apache.org/thread/kxk9g1cmc1x7wd1lvqw2v7tx7qrjlvgm). All in all, thank you very much! :bow: -- 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)
vy commented on issue #2220: URL: https://github.com/apache/logging-log4j2/issues/2220#issuecomment-1902745396 @jvz, the performance benefits of asynchronous loggers are extremely subjective to the deployment environment. Putting aside Log4j team itself is not able to reproduce [the (8 year old!) performance figures shared in the website](https://logging.apache.org/log4j/2.x/performance.html), Google'ing for _"Log4j performance"_ returns a myriad of totally varying experiences. Yet it is a fact that asynchronous loggers are the biggest source of complexity in the code base. I also do not recall user complaints on Disruptor-related preallocation. > What would be difference between this feature and `AsyncAppender` coupled by a JCTools queue that we already have? > We might simply enhance `AsyncAppender` to format the message on the calling thread before it sends it to the worker thread. @ppkarwasz is spot on. I cannot agree more. I think we should first move asynchronous loggers to a separate module and relieve the code base from its complexity and yet-to-be-proven performance benefits. (@ppkarwasz, haven't you had a PR for this somewhere?) I am not inclined to add more to the existing complexity of asynchronous loggers without being able to effectively measure its performance. If we figure out, say, a JCTools-backed `AsyncAppender` can deliver up to 90% of the performance asynchronous loggers do, I am confident that a majority will prefer the simplicity of the former. -- 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
