> > > > > >>>>> async/await comes into play. async/await allows the io
> > > > > operation
> > > > > > to
> > > > > > > > >>>> start
> > > > > > > > >>>>> and the
t; a
> > > > > > > >>>>> synchronization point that is chosen with an await. While
> > > this
> > > > > > works
> > > > > > > >>>> best
> > > > > > > >>>>> with io, it
> > > cpu
> > > > > > >> tasks
> > > > > > >>>>> only pays off it the costs of synchronization and context
> > > > switches
> > > > > is
> > > > > > >>>>> insignificant with respect to
ever
> > > > > >>>> requires us
> > > > > >>>>> to provide both a "normal" api and an async api. But doing so
> > > > rewards
> > > > > >>>> with
> > > > > >&g
gt; > >>>>>> On Wed, 9 May 2018, 16:56 Matt Sicker,
> > wrote:
> > > > >>>>>>
> > > > >>>>>> I'd be interesting in hearing about high performant .NET
> > > > >> applications
> > >
e LMAX Disruptor.
> > > >>>> AFAIK,
> > > >>>>>> that's generally a C++ and Java world.
> > > >>>>>>
> > > >>>>>>> On 9 May 2018 at 08:47, Remko Popma
> > wrote:
> > > >>>>>&
whereupon the application thread
> > >>>> returns
> > >>>>>>> immediately to do other work.
> > >>>>>>> In the background, another thread reads the information to be
> > >> logged
> > >>>>> from
> &
t;>
> >>>>>>> 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
> >>>&g
t;>>>>> 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
>>>>
> > 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
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
> >
> > > Remko
> > >
> > > (Shameless plug) Every java main() method deserves http://picocli.info
> > >
> > > > On May 9, 2018, at 22:06, Dominik Psenner
> wrote:
> > > >
> > > > When implementing the async/await paradi
wait 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?
> > >
> > >
> >
t; > (Shameless plug) Every java main() method deserves
> http://picocli.info
> > > >
> > > > > On May 9, 2018, at 22:06, Dominik Psenner
> > wrote:
> > > > >
> > > > > When implementing the async/await paradigm it would ha
e
> 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?
> > > >
> > > >
&g
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?
> > >
gt;> 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
en 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)
>>
>>
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 la
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 Mon, May 7, 2018 at 2:15 PM William Davis
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
n
the
> > first place.
> >
> > On 7 May 2018 at 12:22, William Davis
> 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.
> first place.
> >
> > On 7 May 2018 at 12:22, William Davis
> 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/cjbhai
r the authors never attempted to donate it upstream in the
> first place.
>
> On 7 May 2018 at 12:22, William Davis wrote:
>
> > Ok then, so are the same Async Appenders available in Log4Net that are in
> > Log4j ?
> > Here are some one I'm using:
> > http
; 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 Appen
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 coul
Oh, no worries, you're on the correct list!
On 7 May 2018 at 09:02, William Davis wrote:
> Sorry I meant to send this to the Log4Net distro
>
> On Mon, May 7, 2018 at 9:47 AM, Matt Sicker wrote:
>
> > Like the Kafka appender's async option? Or like the async logger and
> > appenders?
> >
> > On
Sorry I meant to send this to the Log4Net distro
On Mon, May 7, 2018 at 9:47 AM, Matt Sicker wrote:
> Like the Kafka appender's async option? Or like the async logger and
> appenders?
>
> On 7 May 2018 at 07:38, Remko Popma wrote:
>
> > Log4j core provides about 4 flavours of async logging, sev
Like the Kafka appender's async option? Or like the async logger and
appenders?
On 7 May 2018 at 07:38, Remko Popma 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?
>
>
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 wr
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
32 matches
Mail list logo
