On Thu, May 26, 2016 at 11:33 AM, Matt Sicker <boa...@gmail.com> wrote:
> There's a bson dependency in log4j-nosql as well (from mongo). > Right, the wire format for MongoDB is BSON IIRC. Gary > > On 26 May 2016 at 11:46, Gary Gregory <garydgreg...@gmail.com> wrote: > >> I think we can support BSON through Jackson. That would be interesting >> for 2.7. >> >> Gary >> On May 26, 2016 6:47 AM, "Remko Popma" <remko.po...@gmail.com> wrote: >> >>> 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> >>>> 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 >>> >> > > > -- > Matt Sicker <boa...@gmail.com> > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
