Kirk, Logging in binary format has been on my todo list for a while. We did some preliminary analysis here: https://issues.apache.org/jira/browse/LOG4J2-1305 Your thoughts on this effort would be much appreciated.
Remko On Thursday, May 26, 2016 at 5:32:27 PM UTC+9, Kirk Pepperdine wrote: > > Hi, > > Sorry this might read a bit provocative then intended. In general I > applaud this effort and to be fair I’ve not only picked on Log4J in the > past. IM(not so)HO, all logger and in particular JDK logging has been a > disaster from both an API and underlying design POV. > > > On May 26, 2016, at 9:41 AM, Mikael Ståldal <mikael....@magine.com > <javascript:>> wrote: > > http://12factor.net/logs > > > I actually see little wrong with this approach. It is rare that I run > into an application that isn’t bottlenecked on logging when you combine all > of the problem that come from logging. The JDK logger, because of it’s > design, is responsible for class loader leaks. The API’s in all loggers > encourage programming styles that are responsible for excessive memory > pressure. Though I gripe about the obscene amount of work that logging > frameworks engage in, generally it’s not the logging framework that is > directly responsible for memory pressure, it’s what has to be done to use > the logging framework that is the source of the problem. > > To tackle this I’ve been pushing simple solutions such that the one pushed > here. Loggers should only push messages directly to a sync point and do no > more than that. Anything that injects extra work into a threads workflow > should be discarded. This includes activities such as decorating and/or > reformatting running through appenders.. and so on.... Even record ordering > (if it needs to be done) should happen else where. Additionally, I give the > ( very unpopular) advice) that logging should use binary/machine readable > formats (a practice adopted by Twitter and a number of other players) in > favor of eye readable formats (which tend to be neither human nor machine > readable). In messaging, of which logging is a form of messaging, > information density counts and human readable formats tend to be > exceptionally information sparse. When you combine these techniques you can > get tremendous (orders of magnitude) improvements in performance. As much > as I’m a fan of the disruptor, I fail to see how building on top of it > solves any of the above mentioned problems. > > Kind regards, > Kirk > >
--------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
