I don’t think that creating a AbstractBatchedAppender/Manager would help with batching.
Log4j2 currently already provides core batching support for appender implementors with the `LogEvent.endOfBatch` attribute. LogEvent producers, if they know that more events will follow, should set this attribute to `false` in the produced events. Conversely, when they know they have reached the end of a sequence of events they should set this attribute to `true`. LogEvent consumers should monitor this attribute and postpone expensive operations like flushing a buffer to disk or committing a database transaction until they see an event with `endOfBatch=true`, or until they run out of buffer space, whichever comes first. This results in a very efficient style of batching known as “smart batching” (Google it for more details). Log4j2 internally uses this with async logging: with async logging, the “producer” is the async logging queue. The queue “knows“ whether it’s empty or whether more events will follow immediately and it will set the `endOfBatch` attribute accordingly. Appenders downstream from the async logging queue will flush their buffer when they see the end of a batch. Jochen, you can achieve your objective of efficiently logging a sequence or array of log events by setting the `endOfBatch` attribute to false on all but the last event. On the consumer side, you may buffer all incoming events until you see one with `endOfBatch=true`. I hope this helps. Remko (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 10, 2018, at 6:14, Matt Sicker <boa...@gmail.com> wrote: > > AbstractBatchedAppender/Manager
