You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2016/06/13 18:24:31 UTC
Question about async logger wait strategies
The code has a case for the busy spin strategy, but it's not listed on this
page: <https://logging.apache.org/log4j/2.x/manual/async.html>. Is this
unsupported or should it be added to the docs?
--
Matt Sicker <bo...@gmail.com>
Re: Question about async logger wait strategies
Posted by Remko Popma <re...@gmail.com>.
The busy-spin wait strategy is not something I want to promote since it basically dedicates a full core to the logging background thread. It's there mostly for testing and perhaps for hardcore users who are familiar with the Disruptor.
Sent from my iPhone
> On 2016/06/14, at 3:24, Matt Sicker <bo...@gmail.com> wrote:
>
> The code has a case for the busy spin strategy, but it's not listed on this
> page: <https://logging.apache.org/log4j/2.x/manual/async.html>. Is this
> unsupported or should it be added to the docs?
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Question about async logger wait strategies
Posted by Anthony Maire <ma...@gmail.com>.
If the sources have not been moved, it's still considered as experimental
on master (and it was still experimental on 3.3.5-rc2 tag)
https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/LiteBlockingWaitStrategy.java
2016-06-14 7:15 GMT+02:00 Gary Gregory <ga...@gmail.com>:
> On Mon, Jun 13, 2016 at 9:51 PM, Anthony Maire <ma...@gmail.com>
> wrote:
>
> > Basically you want a logging framework to have as little impact as
> possible
> > on the application. That's why the sleeping strategy is a good
> > general-purpose choice : no allocation, no lock for the application
> > threads, and a CPU consumption when "idle" that will stay pretty low on
> > most OS (it roughly consume 2% of a single core on CentOS/RHEL 7 for
> > example).
> >
> > In most use cases, you don't really care that your logging thread take
> 50µs
> > to wake up when it was idle,
> >
> > Maybe you have a very specific usecase where it make sense to use a
> > "hardcore" strategy to make sure data are logged as fast as possible,
> but I
> > personnaly think that the spin strategy is not really usefull outside of
> > benchmarks when used in a logging framework.
> >
> > Concerning the LiteBlocking strategy, it's still considered as
> experimental
> > according to its javadoc :)
> >
>
> I see "normal" docs here:
>
> https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/LiteBlockingWaitStrategy.html
>
> Looks like 3.3.5 is a the RC stage.
>
> Gary
>
> >
> >
> >
> > 2016-06-14 2:14 GMT+02:00 Remko Popma <re...@gmail.com>:
> >
> > > Currently there isn't but there's no real reason not to. That reminds
> me
> > > we should add LiteBlocking (a standard Disruptor wait strategy).
> > >
> > > Sent from my iPhone
> > >
> > > > On 2016/06/14, at 5:50, Matt Sicker <bo...@gmail.com> wrote:
> > > >
> > > > Also, is there a way to specify a custom WaitStrategy, or is that
> > > pointless?
> > > >
> > > >> On 13 June 2016 at 13:24, Matt Sicker <bo...@gmail.com> wrote:
> > > >>
> > > >> The code has a case for the busy spin strategy, but it's not listed
> on
> > > >> this page: <https://logging.apache.org/log4j/2.x/manual/async.html
> >.
> > Is
> > > >> this unsupported or should it be added to the docs?
> > > >>
> > > >> --
> > > >> Matt Sicker <bo...@gmail.com>
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: Question about async logger wait strategies
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jun 13, 2016 at 9:51 PM, Anthony Maire <ma...@gmail.com>
wrote:
> Basically you want a logging framework to have as little impact as possible
> on the application. That's why the sleeping strategy is a good
> general-purpose choice : no allocation, no lock for the application
> threads, and a CPU consumption when "idle" that will stay pretty low on
> most OS (it roughly consume 2% of a single core on CentOS/RHEL 7 for
> example).
>
> In most use cases, you don't really care that your logging thread take 50µs
> to wake up when it was idle,
>
> Maybe you have a very specific usecase where it make sense to use a
> "hardcore" strategy to make sure data are logged as fast as possible, but I
> personnaly think that the spin strategy is not really usefull outside of
> benchmarks when used in a logging framework.
>
> Concerning the LiteBlocking strategy, it's still considered as experimental
> according to its javadoc :)
>
I see "normal" docs here:
https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/LiteBlockingWaitStrategy.html
Looks like 3.3.5 is a the RC stage.
Gary
>
>
>
> 2016-06-14 2:14 GMT+02:00 Remko Popma <re...@gmail.com>:
>
> > Currently there isn't but there's no real reason not to. That reminds me
> > we should add LiteBlocking (a standard Disruptor wait strategy).
> >
> > Sent from my iPhone
> >
> > > On 2016/06/14, at 5:50, Matt Sicker <bo...@gmail.com> wrote:
> > >
> > > Also, is there a way to specify a custom WaitStrategy, or is that
> > pointless?
> > >
> > >> On 13 June 2016 at 13:24, Matt Sicker <bo...@gmail.com> wrote:
> > >>
> > >> The code has a case for the busy spin strategy, but it's not listed on
> > >> this page: <https://logging.apache.org/log4j/2.x/manual/async.html>.
> Is
> > >> this unsupported or should it be added to the docs?
> > >>
> > >> --
> > >> Matt Sicker <bo...@gmail.com>
> > >
> > >
> > >
> > > --
> > > Matt Sicker <bo...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Question about async logger wait strategies
Posted by Anthony Maire <ma...@gmail.com>.
Basically you want a logging framework to have as little impact as possible
on the application. That's why the sleeping strategy is a good
general-purpose choice : no allocation, no lock for the application
threads, and a CPU consumption when "idle" that will stay pretty low on
most OS (it roughly consume 2% of a single core on CentOS/RHEL 7 for
example).
In most use cases, you don't really care that your logging thread take 50µs
to wake up when it was idle,
Maybe you have a very specific usecase where it make sense to use a
"hardcore" strategy to make sure data are logged as fast as possible, but I
personnaly think that the spin strategy is not really usefull outside of
benchmarks when used in a logging framework.
Concerning the LiteBlocking strategy, it's still considered as experimental
according to its javadoc :)
2016-06-14 2:14 GMT+02:00 Remko Popma <re...@gmail.com>:
> Currently there isn't but there's no real reason not to. That reminds me
> we should add LiteBlocking (a standard Disruptor wait strategy).
>
> Sent from my iPhone
>
> > On 2016/06/14, at 5:50, Matt Sicker <bo...@gmail.com> wrote:
> >
> > Also, is there a way to specify a custom WaitStrategy, or is that
> pointless?
> >
> >> On 13 June 2016 at 13:24, Matt Sicker <bo...@gmail.com> wrote:
> >>
> >> The code has a case for the busy spin strategy, but it's not listed on
> >> this page: <https://logging.apache.org/log4j/2.x/manual/async.html>. Is
> >> this unsupported or should it be added to the docs?
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: Question about async logger wait strategies
Posted by Remko Popma <re...@gmail.com>.
Currently there isn't but there's no real reason not to. That reminds me we should add LiteBlocking (a standard Disruptor wait strategy).
Sent from my iPhone
> On 2016/06/14, at 5:50, Matt Sicker <bo...@gmail.com> wrote:
>
> Also, is there a way to specify a custom WaitStrategy, or is that pointless?
>
>> On 13 June 2016 at 13:24, Matt Sicker <bo...@gmail.com> wrote:
>>
>> The code has a case for the busy spin strategy, but it's not listed on
>> this page: <https://logging.apache.org/log4j/2.x/manual/async.html>. Is
>> this unsupported or should it be added to the docs?
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Question about async logger wait strategies
Posted by Matt Sicker <bo...@gmail.com>.
Also, is there a way to specify a custom WaitStrategy, or is that pointless?
On 13 June 2016 at 13:24, Matt Sicker <bo...@gmail.com> wrote:
> The code has a case for the busy spin strategy, but it's not listed on
> this page: <https://logging.apache.org/log4j/2.x/manual/async.html>. Is
> this unsupported or should it be added to the docs?
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>