On 22.09.2012 17:29, Ralph Goers wrote: > Well, Ceiki's statement about Logback not walking a hierarchy is > partially correct and partially incorrect. In Logback each Logger has > an "effectiveLevel" that is either set or inherited from its parent so > the logger hierarchy isn't "walked" for level filtering. However, if > a Logger has not been configured it will have no appenders and will > have its additivity will default to true. callAppenders will perform > the for loop to call all the appenders (there won't be any) and then > because addictive is true it will delegate to its parent's > callAppenders method, which will do the same. Thus if you have a > hierarchy of 5 or 6 levels with only a root logger configured you will > "walk the hierarchy". However, since the hierarchy is mentioned in a > section on "deciding" (i.e. - filtering) Ceki is absolutely correct > that this should be changed. FWIW, Log4j 2 also has the equivalent of > the effectiveLevel on each Logger.
Thank you for the quick and detailed response. Indeed, the append loop goes through the list of attached appenders. However, as you point out that happens after the decision to log has been taken. This decision is made extremely quickly and involves no "hierarchy walk". I understand that log4j2 configuration is atomic. this might indeed be an improvement upon logback. However, the devil might be in the details. > The next issue is with regard to immediateFlush. Prior to Logback > 1.0.3 the immediateFlush parameter was not available in Logback as an > option on LayoutWrappingEncoder, which is long after I wrote the text > on the performance of writing log events. However, since the option > is now available I have changed the test and rerun it. Note that the > point of that section is not to highlight the differences between the > frameworks but to point out that actually doing logging is > considerably more costly than calling the logging framework and having > the events filtered. Makes sense. > The results from rerunning the test are (I have a much faster MacBook > than when I first wrote the doc): > > Log4j: 1427 > Logback: 1401 > Log4j 2.0: 1963 > > Interestingly, I made a mistake the first time I tried it and > configured it as > > <encoder immediateFlush="false"> > > and didn't get an error and still got the slower results. Joran is very much element oriented. It will ignore XML attributes it does not know about. It will complain about unknown elements though. Again, thank you for the quick response. -- Ceki --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
