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 >>> >
