Re: Event batch

Yes, all async logging, either with AsyncAppender or with Async Loggers will set `endOfBatch` to true on all events where the queue becomes empty. (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 10, 2018, at 19:17, Mikael Ståldal wrote: > >

Re: Event batch

And the same applies to AsyncAppender, right? On 2018-01-10 00:14, Remko Popma wrote: 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

Re: Event batch

Yes we have examples of batching, but the point is that the batch is managed by the appender, so there is no need for a new method in the Appender interface, which was the original point of this thread. Ralph > On Jan 9, 2018, at 2:14 PM, Matt Sicker wrote: > > There are

Re: Event batch

Here is the smart batching link: https://mechanical-sympathy.blogspot.jp/2011/10/smart-batching.html?m=1 Remko (Shameless plug) Every java main() method deserves http://picocli.info On Wed, Jan 10, 2018 at 8:14 Remko Popma wrote: > I don’t think that creating a

Re: Event batch

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

Re: Event batch

There are other examples of handling batched log events. The JDBC appender supports it due to < https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/db/AbstractDatabaseManager.java > This makes me think it might be worthwhile to

Re: Event batch

I guess that you are supposed to use LogEvent.isEndOfBatch() to know when to flush log events to final destination. Our file and stream based appenders do that. See

Re: Event batch

Also, note that each event has to be individually filtered so processing a batch probably won’t work properly. Ralph > On Jan 9, 2018, at 8:04 AM, Ralph Goers wrote: > > The actual code in the AsyncAppender does: > > public void append(final LogEvent logEvent) { >

Re: Event batch

The actual code in the AsyncAppender does: public void append(final LogEvent logEvent) { if (!isStarted()) { throw new IllegalStateException("AsyncAppender " + getName() + " is not active"); } final Log4jLogEvent memento = Log4jLogEvent.createMemento(logEvent,

Re: Event batch

On 2018-01-09 14:46, Apache wrote: > The Logging api only allows you to log a single event at a time so it > doesn?019t make sense for an appender to have a method that accepts multiple > events since it can?019t happen. That said, appenders can queue the events >

Re: Event batch

On 2018-01-09 14:46, Apache wrote: > The Logging api only allows you to log a single event at a time so it > doesn’t make sense for an appender to have a method that accepts multiple > events since it can’t happen. That said, appenders can queue the events and

Re: Event batch

The Logging api only allows you to log a single event at a time so it doesn’t make sense for an appender to have a method that accepts multiple events since it can’t happen. That said, appenders can queue the events and send them downstream in batches. I believe some of the appenders do that

Event batch

Hi, currently writing my first appender, and wondering about the following: The Appender interface specifies a method for logging a single event. However, my custom Appender would greatly benefit in terms of performance, if I could implement an additional method append(LogEvent[] events). Now, I