Yeah, I forgot about the async logger ring buffer. Ralph
> On Sep 24, 2020, at 8:56 AM, Carter Kozak <[email protected]> wrote: > > The AsyncAppender more or less implements what you've described, except it > forwards each event in the batch individually to a delegate appender and sets > the end-of-batch marker on the last one so the API isn't quite as pretty. We > could implement something similar that groups events up to some interval or > maximum capacity before forwarding them, but we'd have to be careful to avoid > creating garbage collection problems. Potentially holding otherwise short > lived parameters in the background can have unintended impact on garbage > collector performance :-) > > The LogEvent.isEndOfBatch method is designed to be sympathetic to the ring > buffer design, where we never create an intermediate collection, but instead > signal when an event is the last in a group that we're aware of. > > Batching comes up fairly frequently for network and database appenders, I > think we've duplicated that code a few times. I'd be supportive of a > canonical implementation (or reusable utility functionality) if we can > extract it out. > > -ck > > On Thu, Sep 24, 2020, at 11:46, Ralph Goers wrote: >> Well, Log4j only feeds events to Appenders one at a time. It has no place to >> aggregate them. However, one Appender could wrap others to create a batch at >> which point this would become useful. I suppose some other component could >> be invented to create a batch but I am not sure where or how that would fit >> into the process - does the batch apply only to a single appender or to >> multiple appenders? What filtering takes place before it is added to the >> batch and what, if any, happens after? >> >> Ralph >> >>> On Sep 24, 2020, at 8:00 AM, Volkan Yazıcı <[email protected]> wrote: >>> >>> If one would look close to existing appenders, almost everyone of them >>> implements a custom batching solution. To the best of my knowledge, this is >>> mainly due to the constraint in the Appender interface: >>> >>> void append(LogEvent event); >>> >>> If this would have been replaced (enhanced?) with >>> >>> void append(List<LogEvent> event); >>> >>> appenders wouldn't need to implement any batching at all. Further, Log4j >>> could have also provided a batching filter replacing all the custom >>> batching code internal to the appenders. >>> >>> What do you think? Am I missing something obvious here? >> >> >>
