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 <remko.po...@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 <boa...@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 <boa...@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 <boa...@gmail.com> > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
