- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-741) SizeAndTimeBasedFNATP not honoring auxilliary parameter...
by Gustavo Hexsel (JIRA) 19 Oct '15

19 Oct '15

1 0

[JIRA] (LOGBACK-1107) Socket Appender sends incorrect log
by Pushpendra Patel (JIRA) 16 Oct '15

16 Oct '15

1 0

[JIRA] (LOGBACK-1106) There is no conversion class registered for conversion word [d]
by benjamin (JIRA) 16 Oct '15

16 Oct '15

1 0

[JIRA] (LOGBACK-992) Rolling File Appender creates .tmp files but never deletes them
by Luca Scopece (JIRA) 16 Oct '15

16 Oct '15

1 0

[JIRA] (LOGBACK-1066) cannot close files with SiftingAppender
by Johann Alvarado (JIRA) 15 Oct '15

15 Oct '15

1 0

[JIRA] (LOGBACK-992) Rolling File Appender creates .tmp files but never deletes them
by Rossella Bozzini (JIRA) 15 Oct '15

15 Oct '15

1 0

[JIRA] (LOGBACK-992) Rolling File Appender creates .tmp files but never deletes them
by Federico Bergamo (JIRA) 15 Oct '15

15 Oct '15

1 0

[JIRA] (LOGBACK-1105) missing ')' in the MySampleLayout.java example
by Ceki Gulcu (JIRA) 09 Oct '15

09 Oct '15

1 0

[JIRA] (LOGBACK-910) AsyncAppenderBase swallows InterruptedException
by Will Gorman (JIRA) 08 Oct '15

08 Oct '15

1 0

How to avoid loading class when logging with a Throwable instance?
by Benimaur Gao 08 Oct '15

08 Oct '15

Hi, When using logback(v1.1.1) in our application, I noticed that logback would massively degrade TPS under high concurrency. It's ok with Logger.error(String msg), Logger.warn(String msg) //etc. But when using Logger.error(String msg, Throwable t) (and any other overrided log method with an additional Throwable instance). Logback seems to try loading every class from StackTraceElement. The stack trace in detail: ------ Thread Name :[BIZ-8-thread-464] java.lang.ClassLoader.loadClass(ClassLoader.java:405) groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:676) groovy.lang.GroovyClassLoader$InnerLoader.loadClass(GroovyClassLoader.java:424) groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:786) groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:774) ch.qos.logback.classic.spi.PackagingDataCalculator.loadClass(PackagingDataCalculator.java:207) ch.qos.logback.classic.spi.PackagingDataCalculator.bestEffortLoadClass(PackagingDataCalculator.java:226) ch.qos.logback.classic.spi.PackagingDataCalculator.computeBySTEP(PackagingDataCalculator.java:138) ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:101) ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:57) ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:147) ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:124) ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:440) ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:396) ch.qos.logback.classic.Logger.error(Logger.java:559) ... ... ------ when under high concurrency, this behavior will cause intensively competing lock, and will slow down the business processing. If I understand correctly, the only purpose of loading a class is retrieving "version" and "codeLocation" info (written in PackagingDataCalculator.computeBySTEP ). In our application, I think we can afford discarding such info to get a performance promotion(IIRC, there is no such info with log4j). Can logback implemention offer a related switch? I also noticed there is a cache in PackagingDataCalculator. After loading a class, a classname to Class map will be put in it. but (hope I am not wrong) it's lifecycle is only in a LoggingEvent, hence not very helpful, I think. Can we make this cache a global registry?

1 0