There are really 2 schools of thought here I think. One side is that this may warrant a significant update to the IAppender interface (or adding a new IAsyncAppender interface) to add in Async methods in addition to the synchronous ones. That seems like a really large effort that would warrant much more planning. In this case I think it would be sufficient to just copy the ForwardingAppender and have it append asynchronously, think AsyncForwardingAppender where we call a method such as: public Task<int> AppendLoopOnAppendersAsync(LoggingEvent loggingEvent) internal Task<int> AppendLoopOnAppendersAsync(LoggingEvent[] loggingEvents)
This is probably the easiest implementation. The other way I've considered is adding in a ConccurrentQueue and an additional thread to pop off the queue and call append. This is likely the more performant method. (And is the method used in the libraries I consume today). On Wed, May 9, 2018 at 10:56 AM, Matt Sicker <boa...@gmail.com> wrote: > I'd be interesting in hearing about high performant .NET applications that > would necessitate the creation of libraries like LMAX Disruptor. AFAIK, > that's generally a C++ and Java world. > > On 9 May 2018 at 08:47, Remko Popma <remko.po...@gmail.com> wrote: > > > In the log4j world, async logging means adding the information to be > > logged to some data structure, whereupon the application thread returns > > immediately to do other work. > > In the background, another thread reads the information to be logged from > > the data structure, potentially transforms it, then renders it to the > > configured layout format and writes it to the configured appender(s). > > > > The data structure may be a standard queue, in which case the > “information > > to be logged” is often a LogEvent instance, or it could be a data > structure > > that is optimized for non-blocking inter-thread handovers, like the LMAX > > Disruptor. I don’t know what the equivalent of the latter is in the .NET > > world. > > > > It seems that concurrent queues in .net may use Async/await under the > > hood. (Based on what I see on SO, like https://stackoverflow.com/ > > questions/7863573/awaitable-task-based-queue) > > > > Not sure if lock-free mechanisms like the lmax disruptor exist. Be aware > > that the background thread needs to employ some waiting strategy until > work > > arrives. The simplest thing is to use some block-notify mechanism: the > > background thread is suspended and woken up by the operating system when > > notified. I assume this is what async/await uses. To be completely > > lock-free, an alternative wait strategy is to busy-spin but this means > > dedicating a core to logging which is a hefty price. In the disruptor > this > > is configurable so if log4j users really want to they can have lock-free > > logging in return for dedicating a cpu core. You may not want or need to > go > > that far. > > > > Remko > > > > (Shameless plug) Every java main() method deserves http://picocli.info > > > > > On May 9, 2018, at 22:06, Dominik Psenner <dpsen...@gmail.com> wrote: > > > > > > When implementing the async/await paradigm it would have to be provided > > as a logging event api and continuously invoked with async down to the > > appender implementations in order for the application code to benefit > from > > true async behavior. Or am I wrong here? > > > > > > > > >> On 2018-05-09 13:48, William Davis wrote: > > >> Jochen, I dont believe that appender has been ported to Log4Net. Maybe > > >> thats what we should do first? Im sure there are other uses cases out > > there > > >> though, which is why we've seen several people roll async appenders in > > the > > >> first place (although it could be a fundamental lack of understanding) > > >> > > >> On Wed, May 9, 2018 at 7:00 AM, Jochen Wiedmann < > > jochen.wiedm...@gmail.com> > > >> wrote: > > >> > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis < > > william.j.dav...@gmail.com> > > >>> wrote: > > >>> > > >>>> I've noticed that there are several Async implementations of > standard > > >>>> appenders out in the wild. Is there a reason none of these have made > > >>> there > > >>>> way into the core product? Is it just b/c no one has taken the time > > to do > > >>> a > > >>>> pull request, or is there some other reason? > > >>> I wonder, why one would create a special async version, when all you > > need > > >>> to do is to put a standard async logger in front of the sync logger > > [1]? > > >>> > > >>> Jochen > > >>> > > >>> 1: https://logging.apache.org/log4j/2.x/manual/async.html# > > MixedSync-Async > > >>> > > > > > > > > > -- > Matt Sicker <boa...@gmail.com> >
