This proposal sounds like the bufferingforwardingappender. On Thu, 10 May 2018, 04:48 William Davis, <william.j.dav...@gmail.com> wrote:
> Agreed, this is what ill be submitting next. > > On Wed, May 9, 2018, 9:47 PM Remko Popma <remko.po...@gmail.com> wrote: > > > Perhaps a reasonable approach would be to work like log4j‘s > AsyncAppender: > > > > This is a class that implements the appender interface by simply adding > > log events to a ConcurrentQueue and returning immediately. When this > > appender is started it starts a background thread that blocks until > events > > become available in the queue. When the queue contains an event, the > > background thread pops it off the queue and appends it to one or more > > underlying appenders. > > > > Note that on the producer (application) side, this looks like any other > > appender. The consumer side (the background thread) is likely where the > > async/await api would be used. > > > > An AsyncAppender must be configured with one or more underlying > appenders. > > (In log4j these appenders must precede the AsyncAppender in the > > configuration so the list of underlying appenders can be immutable). > > > > Hope this helps, > > Remko > > > > (Shameless plug) Every java main() method deserves http://picocli.info > > > > > On May 10, 2018, at 4:04, Matt Sicker <boa...@gmail.com> wrote: > > > > > > One resource I have about fibers is this Java library: > > > https://github.com/puniverse/quasar > > > > > > And the future Java feature: http://openjdk.java.net/projects/loom/ > > > > > > As for continuations, if you're familiar with functional programming, > are > > > essentially deferred functions to be executed along with any curried > > state. > > > It essentially allows you to pause a computation, but you can't use > > things > > > like locks and notifications since those are implemented via threads, > and > > > fibers don't get their own execution context like threads do (hence why > > > they're much faster where applicable due to less context switching and > > data > > > copying needed). > > > > > > > > >> On 9 May 2018 at 13:41, Dominik Psenner <dpsen...@gmail.com> wrote: > > >> > > >> Btw, here is an example of async file io, note that this is a wpf > client > > >> application that stays responsive even though there is a "blocking" > > await > > >> in the button handler: > > >> > > >> > > > https://docs.microsoft.com/en-us/dotnet/standard/io/asynchronous-file-i-o > > >> > > >> and here is an example of async network io which also explains more > > >> in-depth details of how it works: > > >> > > >> https://docs.microsoft.com/en-us/dotnet/csharp/programming- > > >> guide/concepts/async/ > > >> > > >> As a starting point it surely takes time to grasp and caused me some > > >> headache. :-) > > >> > > >> 2018-05-09 20:33 GMT+02:00 Dominik Psenner <dpsen...@gmail.com>: > > >> > > >>> I don't know about fibers or continuations but am interested. Can you > > >>> provide me with some link? > > >>> > > >>> AFAIK, LMAX disruptor intelligently uses hot spins on the cpu where > it > > >>> estimates that hot spinning pays off because an async operation will > > >> finish > > >>> soon. When this is not the case after a few hot spins it will yield > and > > >>> cause a context switch. When I read this up I quickly came to the > > >>> conclusion that such a way makes it very hard to implement something > > >> that's > > >>> reliably fast and stable at the same time. > > >>> > > >>> I can't provide the following with backup information, but as far as > I > > >>> understood the async/await approach it works so well because the > > hardware > > >>> provides interrupts to the operating system when data arrives which > in > > >> turn > > >>> is published to an application via events. As noticed earlier, libuv > > is a > > >>> cross platform library that provides these event api's to an > > application. > > >>> In the dotnet world since the invention of Task and async/await a > libuv > > >> has > > >>> mostly become futile. The kestrel web server, as far as I know, uses > > >> libuv > > >>> under the hoods and is used by some microsoft devs as playground to > > >>> improve the performance of implementations of the async api's > provided > > by > > >>> netstandard. Future versions of asp.netcore will probably no longer > > >> feature > > >>> the kestrel webserver with libuv transports but transports that are > > based > > >>> upon .netstandard System.Net.Sockets. > > >>> > > >>> 2018-05-09 20:17 GMT+02:00 Matt Sicker <boa...@gmail.com>: > > >>> > > >>>> I'm not too familiar with how it's implemented, but that sounds > > similar > > >> to > > >>>> the problems that LMAX was fixing in lock-free queues. The problem > > with > > >>>> typical async/await is lock contention which is addressed in a lower > > >> level > > >>>> fashion in disruptor queues. I think this would all be far easier > with > > >>>> something like fibers or continuations, but I didn't design Java. :) > > >>>> > > >>>>> On 9 May 2018 at 13:09, Dominik Psenner <dpsen...@gmail.com> > wrote: > > >>>>> > > >>>>> Disclaimer: so far I never had to use a library like LMAX > disruptor. > > >>>> After > > >>>>> a lot of brain that I spent into the new async/await approach > that's > > >>>>> available today I even think that a truely high performance .net > > >>>>> application has no need for such library. The following hopefully > > >>>> explains > > >>>>> the why's. > > >>>>> > > >>>>> To me there are mainly two aspects of asynch operations. One is the > > >>>> asynch > > >>>>> nature of multithreading where computational expensive operations > are > > >>>>> offloaded to background threads. The other is async io which allows > > >> the > > >>>> cpu > > >>>>> to continue doing other tasks when the, compared to the cpu cycling > > on > > >>>> its > > >>>>> calculations, veeeery slooooow io like networking is involved. > > >>>>> > > >>>>> Asyc/await with tasks provides, from an api point of view, both. > > >>>>> Traditionally an io operation would either block the cpu while > > waiting > > >>>> for > > >>>>> the io to complete or be buffered/offloaded to a background thread > > and > > >>>>> finished there. The downside of such an approach is that this > > involves > > >>>>> cross thread synchronization points. The actual problem we need to > > >>>> solve is > > >>>>> that we do want the cpu to wait for the slow io. This is where the > > >>>>> async/await comes into play. async/await allows the io operation to > > >>>> start > > >>>>> and the cpu to continue its task. When the async io is complete an > > >> event > > >>>>> fired by the io will trigger the cpu to continue its work on a > > >>>>> synchronization point that is chosen with an await. While this > works > > >>>> best > > >>>>> with io, it also works with cpu intensive tasks that need to be run > > on > > >>>>> background threads. But using this for computational expensive cpu > > >> tasks > > >>>>> only pays off it the costs of synchronization and context switches > is > > >>>>> insignificant with respect to the actual task. > > >>>>> > > >>>>> This said, if an appender involves IO, a client application could > > >>>>> ultimately choose to either fire and forget, wait for the io or > > >> continue > > >>>>> and synchronize later if we provided an async api. This however > > >>>> requires us > > >>>>> to provide both a "normal" api and an async api. But doing so > rewards > > >>>> with > > >>>>> a truely async io. > > >>>>> > > >>>>> Note that this is something what nginx makes heavy use of. libuv > is a > > >>>>> library that provides a few aspects of io as an event based api. > > >>>>> > > >>>>>> On Wed, 9 May 2018, 16:56 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> > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Matt Sicker <boa...@gmail.com> > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Dominik Psenner > > >>> > > >> > > >> > > >> > > >> -- > > >> Dominik Psenner > > >> > > > > > > > > > > > > -- > > > Matt Sicker <boa...@gmail.com> > > >
