I agree with Gary and don't see any problem with exposing async features of the underlying library used in Appenders.
Sure, such features will not be controlled by Log4j queues or locks or other concurrency mechanisms but that is not a problem. We should just document how to enable these features and then it's up to users. Sent from my iPhone > On 13 Dec 2016, at 4:28, Matt Sicker <boa...@gmail.com> wrote: > > The main thing about synchronicity that we're relying on here is that > Appenders are called synchronously. To relieve the performance issues with > doing that on blocking appenders, a user can use async loggers or an async > appender wrapper for simplicity. However, I don't see why an appender > couldn't be asynchronously implemented. > > Adding more explicit support for asynchronous appenders (e.g., a sort of > promise-based API) would be a different story since I think all of our > current appenders use synchronous APIs (except maybe ListAppender?). > >> On 12 December 2016 at 12:55, Gary Gregory <garydgreg...@gmail.com> wrote: >>> On Mon, Dec 12, 2016 at 9:30 AM, Matt Sicker <boa...@gmail.com> wrote: >>> 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. >> >> We do not specify that appender MUST be synchronous anywhere: >> >> - https://logging.apache.org/log4j/2.x/manual/architecture.html >> - https://logging.apache.org/log4j/2.x/manual/appenders.html >> - >> https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/Appender.html >> >> We do talk about how to make code paths explicitly _asynchronous_. >> >> I seems quite OK to surface whatever bells and whistle the underlying >> library provides for an appender. I do not see why we should lock users out >> of these feature. For me, it's about give users choices and documenting them. >> >> Gary >> >> >>> 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? >>>> >>>> -- >>>> >>>> >>>> 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> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > > > -- > Matt Sicker <boa...@gmail.com>
