Hello Remko, Thanks for the insight. I guess my case falls into the wrong end of the pareto law. My project is a low latency application container, so I need to have:
- low latency - log separation (I actually had to implement my own context selector because my logic is more complicated than the standard ClassLoaderContextSelector case) - I want async loggers by default, but deployed apps need to be able to specify sync loggers Right now I'm kinda meeting those requirements using config file, AsyncRoot and my custom selector, but it'd be really great to achieve a performance level like the one that AsyncContextSelector promises. Is there a way of doing that? For what I see on the code, the AsyncLoggerContextSelector's secret sauce is just to always return an AsyncLogger on the newInstance() method. Why is that so much faster than what ClassLoaderLoggerContextSelector does? Thanks! On Fri, Jul 18, 2014 at 1:20 PM, Remko Popma <remko.po...@gmail.com> wrote: > The Async Loggers created with the context selector have a slightly > different mechanism. One of the differences is that LogEvent objects are > re-used. > > However, unless your application is in the low-latency space, I would not > worry too much about the performance difference. Both flavors of Async > Loggers are much faster than the alternative (Async Appenders). > > Your point is valid though. I've been thinking about an alternative way to > configure Async Loggers than via system properties. The work in progress is > tracked in Jira ticket LOG4J2-321 > <https://issues.apache.org/jira/browse/LOG4J2-321>. This is still in the > concept phase though. Meanwhile your best option is probably to use > ClassLoaderContextSelector and configure with <AsyncRoot> and > <AsyncLogger>. > > > > On Fri, Jul 18, 2014 at 10:57 PM, Mariano Gonzalez < > mariano.l.gonza...@gmail.com> wrote: > > > Hello, > > > > According to the performance charts in the documentation, log4j2 has a > > significantly higher throughput when using AsyncLoggerContextSelector > than > > when using all async loggers with any different selector. > > > > Why is that? Is it just because the same context is always reused and > > there's no lookup like in the ClassLoaderContextSelector case? > > > > If I need functionality similar to ClassLoaderContextSelector, is there > any > > way to get a throughput similar to AsyncLoggerContextSelector? > > > > Thanks! > > >
