Without Java 8 support, we'll need our own promise-like API then most likely.
On 12 December 2016 at 11:37, Mikael Ståldal <mikael.stal...@magine.com> wrote: > 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. > -- Matt Sicker <boa...@gmail.com>
