Dave Brosius
added a comment - 14/Aug/13 21:35 notes:
reloading is done by attribute in xml file, so i'm assuming the functionality in initLog4j() is no longer needed
added a duplicate message filter which removes dups after 5
used a standard pattern. folks might want to alter the format. let me know.
logback looks for logback-test.xml first, then logback.xml so specifying loggers for test as -D props not needed.
changed the jmx name to just setLoggingLevel (removing reference to log4j in name)

Yuki Morishita funny, after i attached the patch i was thinking something similar to what you did was better. I'm also thinking that maybe the ccm patch i did to fix 2.1 should use logback-test.xml, but not sure if we want to get that tied into the logback mentality..

Michael Kjellman
added a comment - 05/Sep/13 20:01 Yuki Morishita funny, after i attached the patch i was thinking something similar to what you did was better. I'm also thinking that maybe the ccm patch i did to fix 2.1 should use logback-test.xml, but not sure if we want to get that tied into the logback mentality..

Has log4j2 been considered?
Both log4j (old) and logback has awful java code in its internals using synchronised blocks/methods.

log4j2 seems to take a large step forward here and ensures an application won't lock up in the same way a log4j/logback application can. Such contention locks are not unusual once you increase logging in any high concurrent application.

mck
added a comment - 10/Sep/13 09:59 Has log4j2 been considered?
Both log4j (old) and logback has awful java code in its internals using synchronised blocks/methods.
log4j2 seems to take a large step forward here and ensures an application won't lock up in the same way a log4j/logback application can. Such contention locks are not unusual once you increase logging in any high concurrent application.
log4j2 can be more than 1000x times faster…
http://logging.apache.org/log4j/2.x/manual/async.html#Performance

Jonathan Ellis
added a comment - 22/Oct/13 23:06 We don't log that much so speed is kind of a non-issue for me. Does log4j2 buy us anything else? I'm definitely a fan of logback's auto-reload of config.

No, most people don't log that much. But it's nice to know that you can, if you have to, turn all loggers to DEBUG, or even TRACE, in production without hurting performance. With old-log4j and logback this often isn't possible.

The performance isn't an across the board improvement, as far as i've understood it, but just an improvement that comes from removing all the little contentions from synchronised blocks. I can imagine that this appeals to the c* community, even if it's of little practical meaning for normal production c*

mck
added a comment - 23/Oct/13 06:47 No, most people don't log that much. But it's nice to know that you can, if you have to, turn all loggers to DEBUG, or even TRACE, in production without hurting performance. With old-log4j and logback this often isn't possible.
The performance isn't an across the board improvement, as far as i've understood it, but just an improvement that comes from removing all the little contentions from synchronised blocks. I can imagine that this appeals to the c* community, even if it's of little practical meaning for normal production c*
Log4j2 also provides the auto-reload of configuration files. Other features it offers is at http://logging.apache.org/log4j/2.x/

The message pattern used in default logback.xml is not optimal. '%F' and '%L' conversion words should be avoided because "generating the file (or line) information is not particularly fast" (see http://logback.qos.ch/manual/layouts.html).

Romain Ramanantsiarovana
added a comment - 03/Dec/14 15:09 The message pattern used in default logback.xml is not optimal. '%F' and '%L' conversion words should be avoided because "generating the file (or line) information is not particularly fast" (see http://logback.qos.ch/manual/layouts.html ).