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

Reply via email to