Github user remkop commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
Roman, thanks for the feedback and the benchmarks.
* Understood about keeping the new package-private classes in the same
package as MemoryMappedFilemanager. No problem.
* Thanks for updating to use the new `narrow` method and for clarifying how
extremely long stack traces are handled.
* I still think Log4j components should never throw an Error. I understand
the rationale behind throwing Errors in java.util.concurrent: if these low
level components detect an anomaly it means that the JVM cannot guarantee sane
behaviour for the application. Our case is different because Log4j is an
auxiliary library: logging may fail, but the application should be able to
continue.
It is up to the application to decide whether they want to receive logging
exceptions or not, and users can configure their choice with the
`ignoreExceptions` attribute on `MemoryMappedFileAppender`. New implementations
of MemoryMappedFileAppender should respect this contract.
About testing latency:
Please take a look at
/log4j-core/src/test/java/org/apache/logging/log4j/core/async/perftest/ResponseTimeTest.java
ResponseTimeTest incorporates various lessons I learned from Gil Tene's
[presentations](http://www.infoq.com/presentations/latency-response-time) on
measuring latency as well as discussions on the Mechanical Sympathy mailing
list. (The inner Pacer class is Gil's.) It distinguishes between response time
and service time (see the [sidebar on the Log4j perf
page](https://logging.apache.org/log4j/2.x/performance.html#benchmarks)), and
it allows us to control the load. This is important because latency behaviour
is often different under various workloads.
I am not a fan of using JMH for measuring latency because it only measures
service time, not response time, and there is no way to control the workload,
it just runs at max speed. (Gil explicitly mentioned we probably don't want to
measure latency under maximum load, when the system is under pressure and
latency becomes unpredictable).
Also, it looks like Log4j2AppenderLatencyBenchmark also measures how long
it takes to generate a random number, which is probably not the intention.
The throughput numbers look very promising, I will try to run these tests
on enterprise hardware this week when I have a chance, and report back the
results.
All in all, this is great stuff! Keep 'em coming!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
