Hi all, On Tue, 20 Jun 2023 at 15:13, Matt Sicker <m...@musigma.org> wrote: > As for async logging, if it’s possible to break it into its own module, > that’d be great, particularly to avoid having to set a system property to > enable it.
Looking at where `com.lmax:disruptor`, `com.conversantmedia:disruptor` and `jctools-core` are used, we could break the async features into: * `log4j-core-async` with the async logger, appender and a non-optional dependency on `com.lmax:disruptor`. The async appender does not depend on the Disruptor, but I guess that most async appender users use it just because they don't know any better., * `log4j-core-async-conversant` with the blocking queue offered by `com.conversantmedia:disruptor`, * `log4j-core-async-jctools` with the blocking queue offered by `jctools-core`. In order to split the async functionality into a separate module, we need to address two problems first: 1. Configuration has properties related to async logging: `asyncLoggerConfigDelegate` and `asyncWaitStrategyFactory`. These should be removed before the split, but I don't know what would be the right way to do it. 2. JMX code explicitly references async classes and some JMX-related code spilled out of the `core.jmx` package (e.g. `AsyncLoggerConfig#createRingBufferAdmin`). The last problem probably merits its own discussion. Currently our JMX support offers: * 2 numeric metrics (the remaining capacity of RingBuffer or the async appender queue), * 3 types of notifications (2 from the status logger and one that notifies about reconfigurations), * a lot of configuration data, like the class names of appenders, layouts, etc. In the long run, we should probably replace JMX with some observability framework like Micrometer or JFR. The problem I am having is how to map this data to those frameworks. In the short run we can add some interfaces to our components that allow them to export data via both JMX and in the future Micrometer. Piotr
