August 2011 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-147) RollingPolicy MaxHistory not deleting old files
by Rafael Diaz Maurin (JIRA) 04 Oct '11

04 Oct '11

RollingPolicy MaxHistory not deleting old files ----------------------------------------------- Key: LBCORE-147 URL: http://jira.qos.ch/browse/LBCORE-147 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Environment: linux 2.6.18 64bits apache-tomcat-6.0.20 java/jre1.6.0_18 Reporter: Rafael Diaz Maurin Assignee: Logback dev list The MaxHistory does not do the trick : the old files are not deleted at all : cat logging.xml <appender name="IDP_ACCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/shibboleth-idp/logs/idp-access.log</File> <Append>false</Append> <ImmediateFlush>true</ImmediateFlush> <RollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>/shibboleth-idp/logs/old/idp-access-%d{yyyy-MM-dd_HH-mm}.log.gz</FileNamePattern> <MaxHistory>3</MaxHistory> </RollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%msg%n</Pattern> </layout> </appender> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 35

[JIRA] Created: (LBCORE-218) Incorrect switch fallthrough in the SQL dialect selection
by Pierre Queinnec (JIRA) 04 Oct '11

04 Oct '11

Incorrect switch fallthrough in the SQL dialect selection --------------------------------------------------------- Key: LBCORE-218 URL: http://jira.qos.ch/browse/LBCORE-218 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.30 Reporter: Pierre Queinnec Assignee: Logback dev list There's a break missing in the switch statement for SQL dialects in DBUtil#getDialectFromCode. As HSQLDB and H2 have the same syntax it has gone un-noticed. I'll open a pull request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBCLASSIC-283) SerializationPerfTest crashes due to LoggingEvent being not serializable
by Pierre Queinnec (JIRA) 04 Oct '11

04 Oct '11

SerializationPerfTest crashes due to LoggingEvent being not serializable ------------------------------------------------------------------------ Key: LBCLASSIC-283 URL: http://jira.qos.ch/browse/LBCLASSIC-283 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.30 Reporter: Pierre Queinnec Assignee: Logback dev list SerializationPerfTest crashes due to LoggingEvent being not serializable. This can be trivially fixed using LoggingEventVO. I'll open a pull request with the changes, as I was interested in the benchmark. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBACCESS-25) Infinite loops in AccessConverter#addError
by Pierre Queinnec (JIRA) 30 Sep '11

30 Sep '11

Infinite loops in AccessConverter#addError ------------------------------------------ Key: LBACCESS-25 URL: http://jira.qos.ch/browse/LBACCESS-25 Project: logback-access Issue Type: Bug Affects Versions: 0.9.30 Reporter: Pierre Queinnec Assignee: Logback dev list The addError(String msg) and addError(String msg, Throwable ex) methods seem to be calling themselves in an infinite loop. I'll open a pull-request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBACCESS-17) LogbackValve overrides final start() method from LifecycleBase in Tomcat 7
by Grzegorz Grzybek (JIRA) 30 Sep '11

30 Sep '11

LogbackValve overrides final start() method from LifecycleBase in Tomcat 7 -------------------------------------------------------------------------- Key: LBACCESS-17 URL: http://jira.qos.ch/browse/LBACCESS-17 Project: logback-access Issue Type: Bug Affects Versions: 0.9.26 Reporter: Grzegorz Grzybek Assignee: Logback dev list Priority: Critical {code} java.lang.VerifyError: class ch.qos.logback.access.tomcat.LogbackValve overrides final method start.()V {code} Tomcat 7 has changed the LifecycleBase implementation - it should not override start() but rather startInternal() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 3

[JIRA] Created: (LBCLASSIC-217) Exception stack trace printing starting from root cause
by Tomasz Nurkiewicz (JIRA) 24 Sep '11

24 Sep '11

Exception stack trace printing starting from root cause ------------------------------------------------------- Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 8

[JIRA] Created: (LBCLASSIC-273) Status messages of StatusManager are not cleared upon call to LoggerContext.reset()
by Joern Huxhorn (JIRA) 22 Sep '11

22 Sep '11

Status messages of StatusManager are not cleared upon call to LoggerContext.reset() ----------------------------------------------------------------------------------- Key: LBCLASSIC-273 URL: http://jira.qos.ch/browse/LBCLASSIC-273 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Joern Huxhorn Assignee: Logback dev list See https://github.com/ceki/logback/pull/15 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 8

[JIRA] Created: (LBCLASSIC-289) ConcurrentModificationException when using MDC
by Josh Oddman (JIRA) 20 Sep '11

20 Sep '11

ConcurrentModificationException when using MDC ---------------------------------------------- Key: LBCLASSIC-289 URL: http://jira.qos.ch/browse/LBCLASSIC-289 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.29 Environment: Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode) Darwin aden 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64 Reporter: Josh Oddman Assignee: Logback dev list In some rare cases in multithreaded environment MDC.put throws ConcurrentModificationException. java.util.ConcurrentModificationException: null at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) ~[na:1.6.0_26] at java.util.HashMap$EntryIterator.next(HashMap.java:834) ~[na:1.6.0_26] at java.util.HashMap$EntryIterator.next(HashMap.java:832) ~[na:1.6.0_26] at java.util.HashMap.putAll(HashMap.java:523) ~[na:1.6.0_26] at ch.qos.logback.classic.util.LogbackMDCAdapter.duplicateAndInsertNewMap(LogbackMDCAdapter.java:69) ~[logback-classic-0.9.29.jar:na] at ch.qos.logback.classic.util.LogbackMDCAdapter.put(LogbackMDCAdapter.java:95) ~[logback-classic-0.9.29.jar:na] at org.slf4j.MDC.put(MDC.java:112) ~[slf4j-api-1.6.1.jar:1.6.1] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3

[JIRA] Created: (LBCLASSIC-267) Intermittent ConcurrentModificationException in LoggingEvent.prepareForDeferredProcessing
by Anders Wallgren (JIRA) 20 Sep '11

20 Sep '11

Intermittent ConcurrentModificationException in LoggingEvent.prepareForDeferredProcessing ----------------------------------------------------------------------------------------- Key: LBCLASSIC-267 URL: http://jira.qos.ch/browse/LBCLASSIC-267 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Anders Wallgren Assignee: Logback dev list Occasionally seeing this type of exception: 02:02:27,883 |-ERROR in com.electriccloud.log.AsyncAppender[ASYNC_FILE] - Appender [ASYNC_FILE] failed to append. java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$EntryIterator.next(HashMap.java:834) at java.util.HashMap$EntryIterator.next(HashMap.java:832) at java.util.HashMap.putAllForCreate(HashMap.java:435) at java.util.HashMap.<init>(HashMap.java:225) at ch.qos.logback.classic.spi.LoggingEvent.prepareForDeferredProcessing(LoggingEvent.java:213) at com.electriccloud.log.AsyncAppender.append(AsyncAppender.java:132) at com.electriccloud.log.AsyncAppender.append(AsyncAppender.java:36) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:85) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:64) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:285) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:272) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:473) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:427) at ch.qos.logback.classic.Logger.debug(Logger.java:534) at com.electriccloud.log.Slf4jLog.debug(Slf4jLog.java:66) at com.electriccloud.log.Slf4jLog.log(Slf4jLog.java:202) at com.electriccloud.util.timer.Timer.logElapsed(Timer.java:324) at com.electriccloud.operations.OperationTimingAspect.logOperationPerformance(OperationTimingAspect.java:107) at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616) at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:160) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy23.perform(Unknown Source) at com.electriccloud.operations.OperationInvoker.invoke(OperationInvoker.java:273) at com.electriccloud.operations.OperationCaller.call(OperationCaller.java:127) at com.electriccloud.operations.OperationCaller.call(OperationCaller.java:42) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) at com.electriccloud.util.CommanderThread.run(CommanderThread.java:105) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3

[JIRA] Created: (LBCLASSIC-268) ConcurrentModificationException in LogbackMDCAdapter
by Scott Stanton (JIRA) 20 Sep '11

20 Sep '11

ConcurrentModificationException in LogbackMDCAdapter ---------------------------------------------------- Key: LBCLASSIC-268 URL: http://jira.qos.ch/browse/LBCLASSIC-268 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Environment: JRE 1.6.0_25, Windows 7 64-bit Reporter: Scott Stanton Assignee: Logback dev list Priority: Critical I'm seeing ConcurrentModificationException errors like the following: {panel} 011-05-23T04:53:31.997 | ERROR | Dispatch-001 | | | | OperationCaller | null | java.util.ConcurrentModificationException: null at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) ~[na:1.6.0_21] at java.util.HashMap$EntryIterator.next(HashMap.java:834) ~[na:1.6.0_21] at java.util.HashMap$EntryIterator.next(HashMap.java:832) ~[na:1.6.0_21] at java.util.HashMap.putAll(HashMap.java:523) ~[na:1.6.0_21] at ch.qos.logback.classic.util.LogbackMDCAdapter.put(LogbackMDCAdapter.java:76) ~[logback-classic.jar:na] at org.slf4j.MDC.put(MDC.java:112) ~[slf4j-api.jar:1.6.1] {panel} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3