You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by William Davis <wi...@gmail.com> on 2018/05/07 12:15:51 UTC

Async Appenders

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've had several projects where we need the non-blocking nature of these
appenders to achieve desired performance.

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
+1 :-)

I only have very limited time frames available to hack on log4net but am
happy to help wherever help is needed.

For instance we have to fix the build pipeline to have something to rely on
and allow contributions to be sanity checked by tests.

On 8 May 2018 5:05 p.m., "Matt Sicker" <bo...@gmail.com> wrote:

Please feel free! Our bandwidth for log4net is a bit less since there are
less developers here familiar with C#, but we love contributions. :)


On 7 May 2018 at 17:52, William Davis <wi...@gmail.com> wrote:

> I gotcha, if there is interest Id like to get a pr started.
>
> On Mon, May 7, 2018, 1:25 PM Matt Sicker <bo...@gmail.com> wrote:
>
> > Log4j and Log4net don't share any code, just similar architectures. As
> for
> > why we haven't merged that into log4net, that may because it either was
> > never noticed or the authors never attempted to donate it upstream in
the
> > first place.
> >
> > On 7 May 2018 at 12:22, William Davis <wi...@gmail.com>
> wrote:
> >
> > > Ok then, so are the same Async Appenders available in Log4Net that are
> in
> > > Log4j ?
> > > Here are some one I'm using:
> > > https://github.com/cjbhaines/Log4Net.Async
> > > (my .net standard port: https://github.com/wjdavis5/Log4Net.Async)
> > > Also been looking into an Async Buffering Appender. Just seems we
could
> > get
> > > so much more value out of the core product if these were rolled in.
> (And
> > I
> > > wouldnt have to struggle to get .net core support from ill maintained
> > > repos.)
> > >
> > >
> > >
> > > On Mon, May 7, 2018 at 10:04 AM, Matt Sicker <bo...@gmail.com> wrote:
> > >
> > > > Oh, no worries, you're on the correct list!
> > > >
> > > > On 7 May 2018 at 09:02, William Davis <wi...@gmail.com>
> > > wrote:
> > > >
> > > > > Sorry I meant to send this to the Log4Net distro
> > > > >
> > > > > On Mon, May 7, 2018 at 9:47 AM, Matt Sicker <bo...@gmail.com>
> > wrote:
> > > > >
> > > > > > Like the Kafka appender's async option? Or like the async logger
> > and
> > > > > > appenders?
> > > > > >
> > > > > > On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Log4j core provides about 4 flavours of async logging, several
> of
> > > > which
> > > > > > > use non-blocking data structures.
> > > > > > >
> > > > > > > Can you link to the ones you think should be included?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > Remko
> > > > > > >
> > > > > > > (Shameless plug) Every java main() method deserves
> > > > http://picocli.info
> > > > > > >
> > > > > > > > On May 7, 2018, at 14:15, William Davis <
> > > > william.j.davis5@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've had several projects where we need the non-blocking
> nature
> > > of
> > > > > > these
> > > > > > > > appenders to achieve desired performance.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matt Sicker <bo...@gmail.com>
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by Matt Sicker <bo...@gmail.com>.
Please feel free! Our bandwidth for log4net is a bit less since there are
less developers here familiar with C#, but we love contributions. :)

On 7 May 2018 at 17:52, William Davis <wi...@gmail.com> wrote:

> I gotcha, if there is interest Id like to get a pr started.
>
> On Mon, May 7, 2018, 1:25 PM Matt Sicker <bo...@gmail.com> wrote:
>
> > Log4j and Log4net don't share any code, just similar architectures. As
> for
> > why we haven't merged that into log4net, that may because it either was
> > never noticed or the authors never attempted to donate it upstream in the
> > first place.
> >
> > On 7 May 2018 at 12:22, William Davis <wi...@gmail.com>
> wrote:
> >
> > > Ok then, so are the same Async Appenders available in Log4Net that are
> in
> > > Log4j ?
> > > Here are some one I'm using:
> > > https://github.com/cjbhaines/Log4Net.Async
> > > (my .net standard port: https://github.com/wjdavis5/Log4Net.Async)
> > > Also been looking into an Async Buffering Appender. Just seems we could
> > get
> > > so much more value out of the core product if these were rolled in.
> (And
> > I
> > > wouldnt have to struggle to get .net core support from ill maintained
> > > repos.)
> > >
> > >
> > >
> > > On Mon, May 7, 2018 at 10:04 AM, Matt Sicker <bo...@gmail.com> wrote:
> > >
> > > > Oh, no worries, you're on the correct list!
> > > >
> > > > On 7 May 2018 at 09:02, William Davis <wi...@gmail.com>
> > > wrote:
> > > >
> > > > > Sorry I meant to send this to the Log4Net distro
> > > > >
> > > > > On Mon, May 7, 2018 at 9:47 AM, Matt Sicker <bo...@gmail.com>
> > wrote:
> > > > >
> > > > > > Like the Kafka appender's async option? Or like the async logger
> > and
> > > > > > appenders?
> > > > > >
> > > > > > On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Log4j core provides about 4 flavours of async logging, several
> of
> > > > which
> > > > > > > use non-blocking data structures.
> > > > > > >
> > > > > > > Can you link to the ones you think should be included?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > Remko
> > > > > > >
> > > > > > > (Shameless plug) Every java main() method deserves
> > > > http://picocli.info
> > > > > > >
> > > > > > > > On May 7, 2018, at 14:15, William Davis <
> > > > william.j.davis5@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've had several projects where we need the non-blocking
> nature
> > > of
> > > > > > these
> > > > > > > > appenders to achieve desired performance.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matt Sicker <bo...@gmail.com>
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
I gotcha, if there is interest Id like to get a pr started.

On Mon, May 7, 2018, 1:25 PM Matt Sicker <bo...@gmail.com> wrote:

> Log4j and Log4net don't share any code, just similar architectures. As for
> why we haven't merged that into log4net, that may because it either was
> never noticed or the authors never attempted to donate it upstream in the
> first place.
>
> On 7 May 2018 at 12:22, William Davis <wi...@gmail.com> wrote:
>
> > Ok then, so are the same Async Appenders available in Log4Net that are in
> > Log4j ?
> > Here are some one I'm using:
> > https://github.com/cjbhaines/Log4Net.Async
> > (my .net standard port: https://github.com/wjdavis5/Log4Net.Async)
> > Also been looking into an Async Buffering Appender. Just seems we could
> get
> > so much more value out of the core product if these were rolled in. (And
> I
> > wouldnt have to struggle to get .net core support from ill maintained
> > repos.)
> >
> >
> >
> > On Mon, May 7, 2018 at 10:04 AM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > > Oh, no worries, you're on the correct list!
> > >
> > > On 7 May 2018 at 09:02, William Davis <wi...@gmail.com>
> > wrote:
> > >
> > > > Sorry I meant to send this to the Log4Net distro
> > > >
> > > > On Mon, May 7, 2018 at 9:47 AM, Matt Sicker <bo...@gmail.com>
> wrote:
> > > >
> > > > > Like the Kafka appender's async option? Or like the async logger
> and
> > > > > appenders?
> > > > >
> > > > > On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com> wrote:
> > > > >
> > > > > > Log4j core provides about 4 flavours of async logging, several of
> > > which
> > > > > > use non-blocking data structures.
> > > > > >
> > > > > > Can you link to the ones you think should be included?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Remko
> > > > > >
> > > > > > (Shameless plug) Every java main() method deserves
> > > http://picocli.info
> > > > > >
> > > > > > > On May 7, 2018, at 14:15, William Davis <
> > > william.j.davis5@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've had several projects where we need the non-blocking nature
> > of
> > > > > these
> > > > > > > appenders to achieve desired performance.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matt Sicker <bo...@gmail.com>
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker <bo...@gmail.com>
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: Async Appenders

Posted by Matt Sicker <bo...@gmail.com>.
Log4j and Log4net don't share any code, just similar architectures. As for
why we haven't merged that into log4net, that may because it either was
never noticed or the authors never attempted to donate it upstream in the
first place.

On 7 May 2018 at 12:22, William Davis <wi...@gmail.com> wrote:

> Ok then, so are the same Async Appenders available in Log4Net that are in
> Log4j ?
> Here are some one I'm using:
> https://github.com/cjbhaines/Log4Net.Async
> (my .net standard port: https://github.com/wjdavis5/Log4Net.Async)
> Also been looking into an Async Buffering Appender. Just seems we could get
> so much more value out of the core product if these were rolled in. (And I
> wouldnt have to struggle to get .net core support from ill maintained
> repos.)
>
>
>
> On Mon, May 7, 2018 at 10:04 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> > Oh, no worries, you're on the correct list!
> >
> > On 7 May 2018 at 09:02, William Davis <wi...@gmail.com>
> wrote:
> >
> > > Sorry I meant to send this to the Log4Net distro
> > >
> > > On Mon, May 7, 2018 at 9:47 AM, Matt Sicker <bo...@gmail.com> wrote:
> > >
> > > > Like the Kafka appender's async option? Or like the async logger and
> > > > appenders?
> > > >
> > > > On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com> wrote:
> > > >
> > > > > Log4j core provides about 4 flavours of async logging, several of
> > which
> > > > > use non-blocking data structures.
> > > > >
> > > > > Can you link to the ones you think should be included?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Remko
> > > > >
> > > > > (Shameless plug) Every java main() method deserves
> > http://picocli.info
> > > > >
> > > > > > On May 7, 2018, at 14:15, William Davis <
> > william.j.davis5@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've had several projects where we need the non-blocking nature
> of
> > > > these
> > > > > > appenders to achieve desired performance.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
Ok then, so are the same Async Appenders available in Log4Net that are in
Log4j ?
Here are some one I'm using:
https://github.com/cjbhaines/Log4Net.Async
(my .net standard port: https://github.com/wjdavis5/Log4Net.Async)
Also been looking into an Async Buffering Appender. Just seems we could get
so much more value out of the core product if these were rolled in. (And I
wouldnt have to struggle to get .net core support from ill maintained
repos.)



On Mon, May 7, 2018 at 10:04 AM, Matt Sicker <bo...@gmail.com> wrote:

> Oh, no worries, you're on the correct list!
>
> On 7 May 2018 at 09:02, William Davis <wi...@gmail.com> wrote:
>
> > Sorry I meant to send this to the Log4Net distro
> >
> > On Mon, May 7, 2018 at 9:47 AM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > > Like the Kafka appender's async option? Or like the async logger and
> > > appenders?
> > >
> > > On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com> wrote:
> > >
> > > > Log4j core provides about 4 flavours of async logging, several of
> which
> > > > use non-blocking data structures.
> > > >
> > > > Can you link to the ones you think should be included?
> > > >
> > > > Thanks!
> > > >
> > > > Remko
> > > >
> > > > (Shameless plug) Every java main() method deserves
> http://picocli.info
> > > >
> > > > > On May 7, 2018, at 14:15, William Davis <
> william.j.davis5@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've had several projects where we need the non-blocking nature of
> > > these
> > > > > appenders to achieve desired performance.
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker <bo...@gmail.com>
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: Async Appenders

Posted by Matt Sicker <bo...@gmail.com>.
Oh, no worries, you're on the correct list!

On 7 May 2018 at 09:02, William Davis <wi...@gmail.com> wrote:

> Sorry I meant to send this to the Log4Net distro
>
> On Mon, May 7, 2018 at 9:47 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> > Like the Kafka appender's async option? Or like the async logger and
> > appenders?
> >
> > On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com> wrote:
> >
> > > Log4j core provides about 4 flavours of async logging, several of which
> > > use non-blocking data structures.
> > >
> > > Can you link to the ones you think should be included?
> > >
> > > Thanks!
> > >
> > > Remko
> > >
> > > (Shameless plug) Every java main() method deserves http://picocli.info
> > >
> > > > On May 7, 2018, at 14:15, William Davis <wi...@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've had several projects where we need the non-blocking nature of
> > these
> > > > appenders to achieve desired performance.
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
Sorry I meant to send this to the Log4Net distro

On Mon, May 7, 2018 at 9:47 AM, Matt Sicker <bo...@gmail.com> wrote:

> Like the Kafka appender's async option? Or like the async logger and
> appenders?
>
> On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com> wrote:
>
> > Log4j core provides about 4 flavours of async logging, several of which
> > use non-blocking data structures.
> >
> > Can you link to the ones you think should be included?
> >
> > Thanks!
> >
> > Remko
> >
> > (Shameless plug) Every java main() method deserves http://picocli.info
> >
> > > On May 7, 2018, at 14:15, William Davis <wi...@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've had several projects where we need the non-blocking nature of
> these
> > > appenders to achieve desired performance.
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: Async Appenders

Posted by Matt Sicker <bo...@gmail.com>.
Like the Kafka appender's async option? Or like the async logger and
appenders?

On 7 May 2018 at 07:38, Remko Popma <re...@gmail.com> wrote:

> Log4j core provides about 4 flavours of async logging, several of which
> use non-blocking data structures.
>
> Can you link to the ones you think should be included?
>
> Thanks!
>
> Remko
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On May 7, 2018, at 14:15, William Davis <wi...@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've had several projects where we need the non-blocking nature of these
> > appenders to achieve desired performance.
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by Remko Popma <re...@gmail.com>.
Log4j core provides about 4 flavours of async logging, several of which use non-blocking data structures. 

Can you link to the ones you think should be included?

Thanks!

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On May 7, 2018, at 14:15, William Davis <wi...@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've had several projects where we need the non-blocking nature of these
> appenders to achieve desired performance.

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
That's great! I'm looking forward to hearing from you.

2018-05-11 5:10 GMT+02:00 William Davis <wi...@gmail.com>:

> Well, I cant speak for the entire test suite, but we having been running
> log4net in production on dotnet core since it was released and my ELK stack
> seems to be getting lots of logs :) I'll reach out to Nick at SE and see if
> he can expound upon his previous message.
>
> On Thu, May 10, 2018 at 5:55 PM, Dominik Psenner <dp...@gmail.com>
> wrote:
>
> > Interesting discussion in that pull request, yet it's missing links to
> hard
> > facts what these functionalities, new features, smaller install area, no
> > downsides etc actually are. Have you links to that information?
> >
> > I've said numerous times now that we don't even run the test suite
> against
> > netstandard-1.3. It's no point to add netstandard-2.0 if we don't even
> know
> > whether netstandard-1.3 actually works. And there's an issue somewhere -
> > sorry, no link at the moment - that appears to be a regression related to
> > that target.
> >
> > 2018-05-10 23:09 GMT+02:00 William Davis <wi...@gmail.com>:
> >
> > > Not a bad conversation to have. I would direct you to read this PR from
> > the
> > > SE.Redis library where I argued against netstandard 2.0 inclusion at
> one
> > > point.
> > > https://github.com/StackExchange/StackExchange.Redis/pull/767
> > >
> > > It would probably be worth while to provide explicit support for it.
> > (with
> > > out any additional effort)
> > >
> > > On Thu, May 10, 2018 at 2:42 PM, Dominik Psenner <dp...@gmail.com>
> > > wrote:
> > >
> > > > Sure. This will however block by itself and take care of preserving
> > > > compatibility with the ancient frameworks. With this mentioned, today
> > > might
> > > > be a good day to start a poll on what frameworks log4net should
> > continue
> > > to
> > > > support. In the last days I once more spent numerous hours with the
> > build
> > > > infrastructure and am fed up by the insane build process caused by
> the
> > > > numerous supported frameworks. If we focus on netstandard-1.3 as the
> > base
> > > > framework almost every recent framework can reference log4net. There
> > was
> > > > also a proposal to support netstandard-2.0 but thinking about it I
> see
> > no
> > > > reason to add another framework if we do not need any of the apis
> that
> > > the
> > > > framework provides. If we need netstandard-2.0 functionality we might
> > as
> > > > well provide that functionality as a separate nuget library. Yes,
> > > splitting
> > > > up log4net into several smaller assemblies sounds like a plan to me.
> > > >
> > > > 2018-05-10 18:00 GMT+02:00 William Davis <william.j.davis5@gmail.com
> >:
> > > >
> > > > > Perhaps, but looking at that implementation I see that it is
> locking
> > > in a
> > > > > few places on append. Could this be made a little better by using
> > built
> > > > in
> > > > > ConcurrentCollection types like the ConcurrentQueue?
> > > > >
> > > > > On Thu, May 10, 2018 at 1:23 AM, Dominik Psenner <
> dpsenner@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > This proposal sounds like the bufferingforwardingappender.
> > > > > >
> > > > > > On Thu, 10 May 2018, 04:48 William Davis, <
> > > william.j.davis5@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Agreed, this is what ill be submitting next.
> > > > > > >
> > > > > > > On Wed, May 9, 2018, 9:47 PM Remko Popma <
> remko.popma@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 <bo...@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 <
> dpsenner@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 <
> > > dpsenner@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 <boards@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 <
> > > dpsenner@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, <
> > boards@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.popma@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 <
> > > > > dpsenner@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.wiedmann@gmail.com>
> > > > > > > > >>>>>>>>> wrote:
> > > > > > > > >>>>>>>>>
> > > > > > > > >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > > > > > > >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>> --
> > > > > > > > >>>> Matt Sicker <bo...@gmail.com>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> --
> > > > > > > > >>> Dominik Psenner
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Dominik Psenner
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Matt Sicker <bo...@gmail.com>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Dominik Psenner
> > > >
> > >
> >
> >
> >
> > --
> > Dominik Psenner
> >
>



-- 
Dominik Psenner

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
Well, I cant speak for the entire test suite, but we having been running
log4net in production on dotnet core since it was released and my ELK stack
seems to be getting lots of logs :) I'll reach out to Nick at SE and see if
he can expound upon his previous message.

On Thu, May 10, 2018 at 5:55 PM, Dominik Psenner <dp...@gmail.com> wrote:

> Interesting discussion in that pull request, yet it's missing links to hard
> facts what these functionalities, new features, smaller install area, no
> downsides etc actually are. Have you links to that information?
>
> I've said numerous times now that we don't even run the test suite against
> netstandard-1.3. It's no point to add netstandard-2.0 if we don't even know
> whether netstandard-1.3 actually works. And there's an issue somewhere -
> sorry, no link at the moment - that appears to be a regression related to
> that target.
>
> 2018-05-10 23:09 GMT+02:00 William Davis <wi...@gmail.com>:
>
> > Not a bad conversation to have. I would direct you to read this PR from
> the
> > SE.Redis library where I argued against netstandard 2.0 inclusion at one
> > point.
> > https://github.com/StackExchange/StackExchange.Redis/pull/767
> >
> > It would probably be worth while to provide explicit support for it.
> (with
> > out any additional effort)
> >
> > On Thu, May 10, 2018 at 2:42 PM, Dominik Psenner <dp...@gmail.com>
> > wrote:
> >
> > > Sure. This will however block by itself and take care of preserving
> > > compatibility with the ancient frameworks. With this mentioned, today
> > might
> > > be a good day to start a poll on what frameworks log4net should
> continue
> > to
> > > support. In the last days I once more spent numerous hours with the
> build
> > > infrastructure and am fed up by the insane build process caused by the
> > > numerous supported frameworks. If we focus on netstandard-1.3 as the
> base
> > > framework almost every recent framework can reference log4net. There
> was
> > > also a proposal to support netstandard-2.0 but thinking about it I see
> no
> > > reason to add another framework if we do not need any of the apis that
> > the
> > > framework provides. If we need netstandard-2.0 functionality we might
> as
> > > well provide that functionality as a separate nuget library. Yes,
> > splitting
> > > up log4net into several smaller assemblies sounds like a plan to me.
> > >
> > > 2018-05-10 18:00 GMT+02:00 William Davis <wi...@gmail.com>:
> > >
> > > > Perhaps, but looking at that implementation I see that it is locking
> > in a
> > > > few places on append. Could this be made a little better by using
> built
> > > in
> > > > ConcurrentCollection types like the ConcurrentQueue?
> > > >
> > > > On Thu, May 10, 2018 at 1:23 AM, Dominik Psenner <dpsenner@gmail.com
> >
> > > > wrote:
> > > >
> > > > > This proposal sounds like the bufferingforwardingappender.
> > > > >
> > > > > On Thu, 10 May 2018, 04:48 William Davis, <
> > william.j.davis5@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Agreed, this is what ill be submitting next.
> > > > > >
> > > > > > On Wed, May 9, 2018, 9:47 PM Remko Popma <re...@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 <bo...@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 <dpsenner@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 <
> > dpsenner@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 <bo...@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 <
> > dpsenner@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, <
> boards@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.popma@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 <
> > > > dpsenner@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.wiedmann@gmail.com>
> > > > > > > >>>>>>>>> wrote:
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > > > > > >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> --
> > > > > > > >>>> Matt Sicker <bo...@gmail.com>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> --
> > > > > > > >>> Dominik Psenner
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Dominik Psenner
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Matt Sicker <bo...@gmail.com>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Dominik Psenner
> > >
> >
>
>
>
> --
> Dominik Psenner
>

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
Interesting discussion in that pull request, yet it's missing links to hard
facts what these functionalities, new features, smaller install area, no
downsides etc actually are. Have you links to that information?

I've said numerous times now that we don't even run the test suite against
netstandard-1.3. It's no point to add netstandard-2.0 if we don't even know
whether netstandard-1.3 actually works. And there's an issue somewhere -
sorry, no link at the moment - that appears to be a regression related to
that target.

2018-05-10 23:09 GMT+02:00 William Davis <wi...@gmail.com>:

> Not a bad conversation to have. I would direct you to read this PR from the
> SE.Redis library where I argued against netstandard 2.0 inclusion at one
> point.
> https://github.com/StackExchange/StackExchange.Redis/pull/767
>
> It would probably be worth while to provide explicit support for it. (with
> out any additional effort)
>
> On Thu, May 10, 2018 at 2:42 PM, Dominik Psenner <dp...@gmail.com>
> wrote:
>
> > Sure. This will however block by itself and take care of preserving
> > compatibility with the ancient frameworks. With this mentioned, today
> might
> > be a good day to start a poll on what frameworks log4net should continue
> to
> > support. In the last days I once more spent numerous hours with the build
> > infrastructure and am fed up by the insane build process caused by the
> > numerous supported frameworks. If we focus on netstandard-1.3 as the base
> > framework almost every recent framework can reference log4net. There was
> > also a proposal to support netstandard-2.0 but thinking about it I see no
> > reason to add another framework if we do not need any of the apis that
> the
> > framework provides. If we need netstandard-2.0 functionality we might as
> > well provide that functionality as a separate nuget library. Yes,
> splitting
> > up log4net into several smaller assemblies sounds like a plan to me.
> >
> > 2018-05-10 18:00 GMT+02:00 William Davis <wi...@gmail.com>:
> >
> > > Perhaps, but looking at that implementation I see that it is locking
> in a
> > > few places on append. Could this be made a little better by using built
> > in
> > > ConcurrentCollection types like the ConcurrentQueue?
> > >
> > > On Thu, May 10, 2018 at 1:23 AM, Dominik Psenner <dp...@gmail.com>
> > > wrote:
> > >
> > > > This proposal sounds like the bufferingforwardingappender.
> > > >
> > > > On Thu, 10 May 2018, 04:48 William Davis, <
> william.j.davis5@gmail.com>
> > > > wrote:
> > > >
> > > > > Agreed, this is what ill be submitting next.
> > > > >
> > > > > On Wed, May 9, 2018, 9:47 PM Remko Popma <re...@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 <bo...@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 <dp...@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 <
> dpsenner@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 <bo...@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 <
> dpsenner@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, <bo...@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.popma@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 <
> > > dpsenner@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.wiedmann@gmail.com>
> > > > > > >>>>>>>>> wrote:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > > > > >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> --
> > > > > > >>>> Matt Sicker <bo...@gmail.com>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> Dominik Psenner
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Dominik Psenner
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matt Sicker <bo...@gmail.com>
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Dominik Psenner
> >
>



-- 
Dominik Psenner

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
Not a bad conversation to have. I would direct you to read this PR from the
SE.Redis library where I argued against netstandard 2.0 inclusion at one
point.
https://github.com/StackExchange/StackExchange.Redis/pull/767

It would probably be worth while to provide explicit support for it. (with
out any additional effort)

On Thu, May 10, 2018 at 2:42 PM, Dominik Psenner <dp...@gmail.com> wrote:

> Sure. This will however block by itself and take care of preserving
> compatibility with the ancient frameworks. With this mentioned, today might
> be a good day to start a poll on what frameworks log4net should continue to
> support. In the last days I once more spent numerous hours with the build
> infrastructure and am fed up by the insane build process caused by the
> numerous supported frameworks. If we focus on netstandard-1.3 as the base
> framework almost every recent framework can reference log4net. There was
> also a proposal to support netstandard-2.0 but thinking about it I see no
> reason to add another framework if we do not need any of the apis that the
> framework provides. If we need netstandard-2.0 functionality we might as
> well provide that functionality as a separate nuget library. Yes, splitting
> up log4net into several smaller assemblies sounds like a plan to me.
>
> 2018-05-10 18:00 GMT+02:00 William Davis <wi...@gmail.com>:
>
> > Perhaps, but looking at that implementation I see that it is locking in a
> > few places on append. Could this be made a little better by using built
> in
> > ConcurrentCollection types like the ConcurrentQueue?
> >
> > On Thu, May 10, 2018 at 1:23 AM, Dominik Psenner <dp...@gmail.com>
> > wrote:
> >
> > > This proposal sounds like the bufferingforwardingappender.
> > >
> > > On Thu, 10 May 2018, 04:48 William Davis, <wi...@gmail.com>
> > > wrote:
> > >
> > > > Agreed, this is what ill be submitting next.
> > > >
> > > > On Wed, May 9, 2018, 9:47 PM Remko Popma <re...@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 <bo...@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 <dp...@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 <dpsenner@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 <bo...@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 <dp...@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, <bo...@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.popma@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 <
> > dpsenner@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.wiedmann@gmail.com>
> > > > > >>>>>>>>> wrote:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > > > >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> --
> > > > > >>>> Matt Sicker <bo...@gmail.com>
> > > > > >>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> Dominik Psenner
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Dominik Psenner
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matt Sicker <bo...@gmail.com>
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Dominik Psenner
>

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
Sure. This will however block by itself and take care of preserving
compatibility with the ancient frameworks. With this mentioned, today might
be a good day to start a poll on what frameworks log4net should continue to
support. In the last days I once more spent numerous hours with the build
infrastructure and am fed up by the insane build process caused by the
numerous supported frameworks. If we focus on netstandard-1.3 as the base
framework almost every recent framework can reference log4net. There was
also a proposal to support netstandard-2.0 but thinking about it I see no
reason to add another framework if we do not need any of the apis that the
framework provides. If we need netstandard-2.0 functionality we might as
well provide that functionality as a separate nuget library. Yes, splitting
up log4net into several smaller assemblies sounds like a plan to me.

2018-05-10 18:00 GMT+02:00 William Davis <wi...@gmail.com>:

> Perhaps, but looking at that implementation I see that it is locking in a
> few places on append. Could this be made a little better by using built in
> ConcurrentCollection types like the ConcurrentQueue?
>
> On Thu, May 10, 2018 at 1:23 AM, Dominik Psenner <dp...@gmail.com>
> wrote:
>
> > This proposal sounds like the bufferingforwardingappender.
> >
> > On Thu, 10 May 2018, 04:48 William Davis, <wi...@gmail.com>
> > wrote:
> >
> > > Agreed, this is what ill be submitting next.
> > >
> > > On Wed, May 9, 2018, 9:47 PM Remko Popma <re...@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 <bo...@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 <dp...@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 <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <
> dpsenner@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.wiedmann@gmail.com>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > > >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> Matt Sicker <bo...@gmail.com>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> Dominik Psenner
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Dominik Psenner
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matt Sicker <bo...@gmail.com>
> > > >
> > >
> >
>



-- 
Dominik Psenner

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
Perhaps, but looking at that implementation I see that it is locking in a
few places on append. Could this be made a little better by using built in
ConcurrentCollection types like the ConcurrentQueue?

On Thu, May 10, 2018 at 1:23 AM, Dominik Psenner <dp...@gmail.com> wrote:

> This proposal sounds like the bufferingforwardingappender.
>
> On Thu, 10 May 2018, 04:48 William Davis, <wi...@gmail.com>
> wrote:
>
> > Agreed, this is what ill be submitting next.
> >
> > On Wed, May 9, 2018, 9:47 PM Remko Popma <re...@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 <bo...@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 <dp...@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 <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <dpsenner@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.wiedmann@gmail.com>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Matt Sicker <bo...@gmail.com>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Dominik Psenner
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Dominik Psenner
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > >
> >
>

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
This proposal sounds like the bufferingforwardingappender.

On Thu, 10 May 2018, 04:48 William Davis, <wi...@gmail.com>
wrote:

> Agreed, this is what ill be submitting next.
>
> On Wed, May 9, 2018, 9:47 PM Remko Popma <re...@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 <bo...@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 <dp...@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 <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Matt Sicker <bo...@gmail.com>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Dominik Psenner
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Dominik Psenner
> > >>
> > >
> > >
> > >
> > > --
> > > Matt Sicker <bo...@gmail.com>
> >
>

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
Agreed, this is what ill be submitting next.

On Wed, May 9, 2018, 9:47 PM Remko Popma <re...@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 <bo...@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 <dp...@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 <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> >>>>>>> william.j.davis5@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 <bo...@gmail.com>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Matt Sicker <bo...@gmail.com>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Dominik Psenner
> >>>
> >>
> >>
> >>
> >> --
> >> Dominik Psenner
> >>
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>

Re: Async Appenders

Posted by Remko Popma <re...@gmail.com>.
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 <bo...@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 <dp...@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 <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On Mon, May 7, 2018 at 2:15 PM William Davis <
>>>>>>> william.j.davis5@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 <bo...@gmail.com>
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Dominik Psenner
>>> 
>> 
>> 
>> 
>> --
>> Dominik Psenner
>> 
> 
> 
> 
> -- 
> Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by Matt Sicker <bo...@gmail.com>.
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 <dp...@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 <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> >> > > > >> wrote:
> >> > > > >>
> >> > > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> >> > > > william.j.davis5@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 <bo...@gmail.com>
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
> >
> >
> >
> > --
> > Dominik Psenner
> >
>
>
>
> --
> Dominik Psenner
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
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 <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
>> > > > >> wrote:
>> > > > >>
>> > > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
>> > > > william.j.davis5@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 <bo...@gmail.com>
>> > >
>> >
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> Dominik Psenner
>



-- 
Dominik Psenner

Re: Async Appenders

Posted by Dominik Psenner <dp...@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 <bo...@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 <dp...@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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > > william.j.davis5@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 <bo...@gmail.com>
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>



-- 
Dominik Psenner

Re: Async Appenders

Posted by Matt Sicker <bo...@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 <dp...@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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > william.j.davis5@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 <bo...@gmail.com>
> >
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
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, <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> > >> wrote:
> > >>
> > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > william.j.davis5@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 <bo...@gmail.com>
>

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
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 <bo...@gmail.com> 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 <wi...@gmail.com> 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 <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > > william.j.davis5@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 <bo...@gmail.com>
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: Async Appenders

Posted by Matt Sicker <bo...@gmail.com>.
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 <wi...@gmail.com> 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 <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > > william.j.davis5@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 <bo...@gmail.com>
> >
>



-- 
Matt Sicker <bo...@gmail.com>

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
 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 <bo...@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 <re...@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 <dp...@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.wiedmann@gmail.com>
> > >> wrote:
> > >>
> > >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> > william.j.davis5@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 <bo...@gmail.com>
>

Re: Async Appenders

Posted by Matt Sicker <bo...@gmail.com>.
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 <re...@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 <dp...@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.wiedmann@gmail.com>
> >> wrote:
> >>
> >>> On Mon, May 7, 2018 at 2:15 PM William Davis <
> william.j.davis5@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 <bo...@gmail.com>

Re: Async Appenders

Posted by Remko Popma <re...@gmail.com>.
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 <dp...@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 <jo...@gmail.com>
>> wrote:
>> 
>>> On Mon, May 7, 2018 at 2:15 PM William Davis <wi...@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
>>> 
>

Re: Async Appenders

Posted by Dominik Psenner <dp...@gmail.com>.
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 <jo...@gmail.com>
> wrote:
>
>> On Mon, May 7, 2018 at 2:15 PM William Davis <wi...@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
>>

Re: Async Appenders

Posted by William Davis <wi...@gmail.com>.
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 <jo...@gmail.com>
wrote:

> On Mon, May 7, 2018 at 2:15 PM William Davis <wi...@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
>

Re: Async Appenders

Posted by Jochen Wiedmann <jo...@gmail.com>.
On Mon, May 7, 2018 at 2:15 PM William Davis <wi...@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