The java.util.concurrent.Future is quite useless since it does not support callbacks. We should not use it.
On Mon, Dec 12, 2016 at 6:30 PM, 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. 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> > -- [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.
