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? >> >> -- >> [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> > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
