Here is a quick example of the #1 impl : https://github.com/apache/logging-log4net/pull/21
On Wed, May 9, 2018 at 1:59 PM, Matt Sicker <[email protected]> wrote: > A quick search found this library: < > https://github.com/disruptor-net/Disruptor-net>. May be worth looking at. > > On 9 May 2018 at 12:09, William Davis <[email protected]> wrote: > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 < > > > > [email protected]> > > > > >> wrote: > > > > >> > > > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis < > > > > [email protected]> > > > > >>> 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 <[email protected]> > > > > > > > > > -- > Matt Sicker <[email protected]> >
