Re: Console performance

Yes writing to the console on either Windows or Linux was ~50x(!) slower than writing to a file. This is documented on the log4j performance page. Mikael’s JIRA ticket on the direct option has some perf numbers: https://issues.apache.org/jira/browse/LOG4J2-1395 I seem to remember that the direc

Re: [log4j] Better init status logger message

Done: https://issues.apache.org/jira/browse/LOG4J2-2302 Gary On Sun, Apr 1, 2018 at 12:08 PM, Matt Sicker wrote: > Makes sense to me. Debugging weird configurations should always be easier. > > On 1 April 2018 at 12:41, Gary Gregory wrote: > > > Hi All: > > > > Instead of a status logger messa

Re: Console performance

>From what I remember, we didn't enable it by default because there's no official API docs about if it's supported by non-OpenJDK implementations. On 2 April 2018 at 12:28, Ralph Goers wrote: > They do it to allow Kubernetes to manage the configuration externally in a > generic way. Then it does

Re: Console performance

They do it to allow Kubernetes to manage the configuration externally in a generic way. Then it doesn’t matter if it is a Java app, Ruby, Python, C#, etc. They can use the same configuration on every container to do the same thing. What I am most interested in was the discussion we had some time

Re: Console performance

In general, I believe writing stuff to stdout is a bad idea, even if you are just using it as a `debug` log.  the itchy thing for me is that there’s always another extra “piping” / “redirect” which has to happen for _persisting_ the log data. If you want to do that, why not just write it to a fi

Re: Console performance

The question is, what is the overhead when the console appender is redirected somewhere besides the console? Apparently the kubernetes configuration redirects stdout to somewhere else where it can be sent to Splunk or some other log aggregation tool. Raph > On Apr 2, 2018, at 10:08 AM, Matt Si

Re: Console performance

I always set direct="true" on console appenders (it's false by default because we added that option later). On 2 April 2018 at 12:05, Gary Gregory wrote: > I'm sure this is OS dependent as well. I've only seen the obvious: if you > log a ton of data, say at the DEBUG level, and enable DEBUG, the

Re: Console performance

I'm sure this is OS dependent as well. I've only seen the obvious: if you log a ton of data, say at the DEBUG level, and enable DEBUG, then yeah, things are going to slow down. Obvious. The complain I usually hear is that our server logs too much DEBUG data, and that users do not know which log ca

Console performance

Some of my team members at work are looking to move some services into Docker containers managed by Kubernetes following the guidance at https://12factor.net/logs . We have guidance that shows writing to the console is terrible and I remember having a discussion that

[log4j] LOG4J2-2299 and a bit of LOG4J2-2301

Hi Folks, I've put together a fix for LOG4J2-2299, where events lose parameters and format as they are passed between disruptors. I'm not sure where this lies on the spectrum of idea vs patch, and would appreciate feedback before merging. Commit is available here: https://github.com/cakofony/loggi

LOG4J2-2299 (and a bit of LOG4J2-2301)

Hey Folks, I've put together a fix for LOG4J2-2299, where events lose parameters and format as they are passed between disruptors. I'm not sure where this lies on the spectrum of idea vs patch, and would appreciate feedback before merging. Patch is attached, and also available here: https://github

[log4j] LOG4J2-2300

Hi All: I did something bad to the pooch when I created the new plugin for JDBC and Apache Commons DBCP 2. LOG4J2-2300 is fixed in the release 2.x branch and master. So if anyone has an itch to RM a release, I would be grateful. Gary