There was talk about making NIO/channel-based appenders that would get nearly async performance without using async loggers or appenders. I'm not so sure that making an appender's implementation asynchronous/non-blocking is against the architecture. Though adding API support for Future or CompleteableFuture or something similar would be interesting. It could certainly open up some avenues for asynchronous optimizations or new ideas.
On 12 December 2016 at 11:16, Mikael Ståldal <mikael.stal...@magine.com> wrote: > This issue: https://issues.apache.org/jira/browse/LOG4J2-1733 > raises an architectural issue. > > As far as I understand, Log4j assumes that regular appenders (the > AsyncAppender is a special case) to be synchronous, and > provides AsyncAppender and async loggers if you want async behavior. > > It would be easy to fulfill LOG4J2-1733 and add an option to make > KafkaAppeder asynchronous. But that that would violate the contract, and > might cause problems that are not so easy to foresee. > > However, refusing LOG4J2-1733 and insisting in keeping all appenders > synchronous, even when real async I/O is available, will limit performance. > > Should we refine the appender interface and explicitly allow them to be > asynchronous, changing AsyncAppender and parts of core to make use of this > to optimize processing? > > Thoughts? > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. > -- Matt Sicker <boa...@gmail.com>
