Take a look at http://logging.apache.org/log4j/2.x/manual/architecture.html.
The configuration creates the LoggerConfig objects, not the Loggers. Loggers
are created by applications and associated with LoggerConfigs.
XMLConfiguration and JSONConfiguration are responsible for parsing their
re
Thanks Remko and Matt for your comments.
I will take your suggestions and let you know how it goes.
Just out of curiosity (I don't like to use libraries blindly and way too
curious), where are the loggers instantiated/configured?? I followed the
code of XmlConfiguration but it seems to only parse
Mariano, to clarify, I would recommend that you keep your custom context
selector simple and only use it for the log separation that you mentioned.
I would not recommend that you also somehow try to merge the functionality
of AsyncLoggerContextSelector in your context selector. From a performance
p
Matt, not sure what you mean. Mariano needs to develop his own
ContextSelector to achieve log separation.
So he cannot use the AsyncLoggerContextSelector.
Mariano, I would not be overly concerned with the performance results
mentioned on the async logger manual page. Bear in mind that in that
perf
Well, the way to go that's similar to the async version is to use the
BasicContextSelector which contains a singleton LoggerContext. Otherwise,
you'll have to keep your own registry that can be looked up dynamically
such as through reflection of the caller stack and other fun design
problems. :)
Hello Remko,
I'm still a couple of days away from starting my own performance testing.
I'm taking about the difference in the async loggers manual page, more
specifically, the charts that compare sync loggers, to mixed async loggers
against purely async loggers. Since I need to build my own select
I think he's talking about the ClassLoaderContextSelector which attempts to
find the logger context through several different ways. Using the
sun.reflect.Reflection class to get the caller class itself is one of those
techniques which might slow things down a little.
I actually have a change to Lo
Hi,
No that is incorrect.
If you do not specify AsyncLoggerContextSelector but instead configure with
and loggers, you _do_ need the disruptor jar on
the classpath and this does _not_ use AsyncAppender. AsyncAppender is
completely separate from Async Loggers. Async Loggers (mixed or all async)
us
Hello Remko,
I think I found the difference. AsyncLoggerContextSelector always returns
the same instance of AsyncLoggerContext, which in turns always returns
instances of AsyncLogger, which uses disruptor to handle concurrency.
However, with any other selector, a standard Logger instance is retur
To be honest, I haven't investigated in detail the reason for the
difference in throughput in the performance test.
Are you measuring the performance of your application container, and can
you see an improvement when using Async Loggers?
Do you see a large difference in performance _in your applic
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
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
Log
12 matches
Mail list logo
