January 2009 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-61) TimeBasedRollingPolicy can not be used with any other triggering policies
by Szel Zoltan (JIRA) 07 Aug '09

07 Aug '09

TimeBasedRollingPolicy can not be used with any other triggering policies ------------------------------------------------------------------------- Key: LBCORE-61 URL: http://jira.qos.ch/browse/LBCORE-61 Project: logback-core Issue Type: Bug Reporter: Szel Zoltan Assignee: Logback dev list Priority: Critical If someone would like to have a time based rolling policy with a size based triggering policy, than the user will get a NullPointerException,: at ch.qos.logback.core.rolling.helper.Compress.GZCompress(Compress.java:130) at ch.qos.logback.core.rolling.TimeBasedRollingPolicy.rollover(TimeBasedRollingPolicy.java:142) at ch.qos.logback.core.rolling.RollingFileAppender.rollover(RollingFileAppender.java:91) at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:116) at ch.qos.logback.core.WriterAppender.append(WriterAppender.java:124) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:81) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:282) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:266) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:487) at ch.qos.logback.classic.Logger.filterAndLog(Logger.java:479) The cause of this issue is the isTriggeringEvent method in the TimeBasedRollingPolicy which has a side effect, namely it prepares the file name of the file which is about to rotate. If someone uses a triggering policy other than the same TimeBasedRollingPolicy, than the isTriggeringEvent method will not be called, hence the elapsedPeriodFileName will be null, hence a null pointer exception will be thrown in the start of the compression or while renaming. Please modify the isTriggeringEvent to not have this side effect + the rollover logic to capture the time information from the current event. Thanks, Zoltan -- 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 5

[JIRA] Created: (LBCORE-59) Support for reconfiguration at runtime
by Michael Osipov (JIRA) 20 Jul '09

20 Jul '09

Support for reconfiguration at runtime -------------------------------------- Key: LBCORE-59 URL: http://jira.qos.ch/browse/LBCORE-59 Project: logback-core Issue Type: New Feature Components: Joran Affects Versions: 0.9.9 Reporter: Michael Osipov Assignee: Logback dev list Joran should support reconfiguration at runime like log4j's DOMConfigurator#configureAndWatch. -- 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

4 8

[JIRA] Created: (LBCORE-60) Allow rolling based on time or file size
by Szel Zoltan (JIRA) 02 Jul '09

02 Jul '09

Allow rolling based on time or file size ---------------------------------------- Key: LBCORE-60 URL: http://jira.qos.ch/browse/LBCORE-60 Project: logback-core Issue Type: New Feature Components: Appender Affects Versions: 0.9.9 Reporter: Szel Zoltan Assignee: Logback dev list The rolling grouping file appender allows to roll over on a specific interval(TimeBasedRollingPolicy) or when the log file has reached a specific file size. But unfortunately Logback does not support both to use together. For example if i want to roll over every day but i also want to roll the file when it is greater than 100MB. Please consider adding this feature to Logback and feel free to contact me if further clarification is required. Thanks, Zoltan Szel -- 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

4 9

[JIRA] Created: (LBCORE-58) AppenderBase doAppend is synchronized causing significant performance problems when calling appenders.
by Ralph Goers (JIRA) 26 Jun '09

26 Jun '09

AppenderBase doAppend is synchronized causing significant performance problems when calling appenders. ------------------------------------------------------------------------------------------------------ Key: LBCORE-58 URL: http://jira.qos.ch/browse/LBCORE-58 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.10 Environment: All Reporter: Ralph Goers Assignee: Logback dev list Slow appenders cause Logback to be a significant bottleneck in the system. AppenderBase doAppend is synchronized to allow Appenders to be threadsafe. This is an extremely poor way to accomplish that. Many Appenders are slow since they are dealing with I/O of some kind but may be thread safe. Where they are not they should deal with the issue at the smallest granularity possible. AppenderBase must be changed to not be synchronized and any Appenders that are not thread safe should be modified appropriately. -- 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 6

[JIRA] Created: (LBCORE-62) Dinimish contention among concurrent threads when using logback
by Ceki Gulcu (JIRA) 26 Jun '09

26 Jun '09

Dinimish contention among concurrent threads when using logback --------------------------------------------------------------- Key: LBCORE-62 URL: http://jira.qos.ch/browse/LBCORE-62 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.9 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Fix For: 0.9.10 We should strive to diminish interference among concurrent threads when using logback. -- 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

1 1

[JIRA] Created: (LBSITE-27) Add chapter/section in the documentation abuout migrating log4j appender to logback
by Ceki Gulcu (JIRA) 09 Feb '09

09 Feb '09

Add chapter/section in the documentation abuout migrating log4j appender to logback ----------------------------------------------------------------------------------- Key: LBSITE-27 URL: http://jira.qos.ch/browse/LBSITE-27 Project: logback-site Issue Type: Task Affects Versions: 0.9.14 Reporter: Ceki Gulcu Assignee: Ceki Gulcu There should also be an FAQ entry pointing to the migration doc. -- 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

1 1

[JIRA] Created: (LBCORE-65) Better documentation on Joran
by Ceki Gulcu (JIRA) 04 Feb '09

04 Feb '09

Better documentation on Joran ----------------------------- Key: LBCORE-65 URL: http://jira.qos.ch/browse/LBCORE-65 Project: logback-core Issue Type: Task Components: Joran Affects Versions: 0.9.10 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Joran should be better documented -- 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

1 3

[JIRA] Created: (LBSITE-24) Document default component class mapping rules
by Ceki Gulcu (JIRA) 04 Feb '09

04 Feb '09

Document default component class mapping rules ---------------------------------------------- Key: LBSITE-24 URL: http://jira.qos.ch/browse/LBSITE-24 Project: logback-site Issue Type: Task Components: Documentation Affects Versions: 0.9.15 Reporter: Ceki Gulcu Assignee: Ceki Gulcu In relation with LBCLASSIC-103, there should be documentation about default component class mapping rules. -- 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

1 2

[JIRA] Created: (LBCORE-66) Document the valueOf convention
by Ceki Gulcu (JIRA) 04 Feb '09

04 Feb '09

Document the valueOf convention ------------------------------- Key: LBCORE-66 URL: http://jira.qos.ch/browse/LBCORE-66 Project: logback-core Issue Type: Sub-task Components: Joran Reporter: Ceki Gulcu Assignee: Logback dev list Joran now assumes that any class which has a static valueOf method taking a String as an argument can be built from a string. Level, Duration and FileSize classes follow this convention. -- 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

1 2

IllegalMonitorStateException in AppenderAttachableImpl.appendLoopOnAppenders()
by Szel, Zoltan (IDEAS) 03 Feb '09

03 Feb '09

Hi, We have hit the exception mentioned in the subject in one of our applications. We are using JDK 6 and Logback 0.9.14. Here is the stacktrace: Caused by: java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:363) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1253) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:745) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:64) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:411) at ch.qos.logback.classic.Logger.debug(Logger.java:504) I have checked the code and it seems to me this can only happen if the readLock.lock() method throws an exception: public int appendLoopOnAppenders(E e) { 56<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> int size = 0; 57<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> try { 58<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> r.lock(); 59<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> for (Appender<E> appender : appenderList) { 60<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> appender.doAppend(e); 61<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> size++; 62<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> } 63<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> } finally { 64<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> r.unlock(); 65<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> } 66<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> return size; 67<http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.h…> } if r.lock() in line 58 throws an exception for some reason than in the finally block the unlock will throw also an exception which will hide the original one. I cannot see any other reason why the unlock would throw this exception in this scenario. I am not yet able to reproduce it, but I thought this exception worth a mail. The only suggestion I have for now is to move the r.lock() call out of the try block, because if that is the bad guy, than we would have the original exception propagated. If I have more information on this issue I will update this thread. Regards, Zoltan Szel Morgan Stanley | IDEAS PRACTICE AREAS Lechner Odon fasor 8 | Floor 07 Budapest, 1095 Phone: +36 1 881-3978 Zoli.Szel(a)MorganStanley.com<mailto:Zoli.Szel@MorganStanley.com> -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

4 9