[JIRA] Created: (LBCORE-87) Missing error reporting if to appenders are configured with the same name
Missing error reporting if to appenders are configured with the same name ------------------------------------------------------------------------- Key: LBCORE-87 URL: http://jira.qos.ch/browse/LBCORE-87 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.13 Reporter: Michael Franz Assignee: Logback dev list If two appenders within a joran configuration use the same name joran does not abort with an error. This may lead to not working system. An example that actually happend: An appender configuration for a RollingFileAppender with a FixedWindowRollingPolicy and a SizeBasedTriggeringPolicy was copied from one file into another, but the application included both files at once. Since all debug messages are to be written in this file it growed quite fast, but the system worked normally at first. But when rolling occurs the file could not be renamed (two file handles to the same file), so the rename by copy fallback started. After copying the deletion still failed. So the current log file is still over the rolling limit. As you might already can imaging, this happens from now on for all log messages to be written and makes the system almost only doing copying files. BTW.: The failure of the deletion of the current log file is also not reported as an error to the status manager. -- 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
[ http://jira.qos.ch/browse/LBCORE-87?page=com.atlassian.jira.plugin.system.is... ] Ceki Gulcu commented on LBCORE-87: ---------------------------------- Hello Franz, Could you please attach a sample configuration file for completeness sake? Thank you.
Missing error reporting if to appenders are configured with the same name -------------------------------------------------------------------------
Key: LBCORE-87 URL: http://jira.qos.ch/browse/LBCORE-87 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.13 Reporter: Michael Franz Assignee: Logback dev list
If two appenders within a joran configuration use the same name joran does not abort with an error. This may lead to not working system. An example that actually happend: An appender configuration for a RollingFileAppender with a FixedWindowRollingPolicy and a SizeBasedTriggeringPolicy was copied from one file into another, but the application included both files at once. Since all debug messages are to be written in this file it growed quite fast, but the system worked normally at first. But when rolling occurs the file could not be renamed (two file handles to the same file), so the rename by copy fallback started. After copying the deletion still failed. So the current log file is still over the rolling limit. As you might already can imaging, this happens from now on for all log messages to be written and makes the system almost only doing copying files. BTW.: The failure of the deletion of the current log file is also not reported as an error to the status manager.
-- 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
[ http://jira.qos.ch/browse/LBCORE-87?page=com.atlassian.jira.plugin.system.is... ] Michael Franz commented on LBCORE-87: ------------------------------------- An example configuration that provokes the missbehaviour: <configuration> <appender name="Debug" class="ch.qos.logback.core.rolling.RollingFileAppender"> <bufferedIO>true</bufferedIO> <File>D:/temp/logtest/debug.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <FileNamePattern>D:/temp/logtest/debug.%i.log</FileNamePattern> <MinIndex>1</MinIndex> <MaxIndex>5</MaxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>20KB</MaxFileSize> </triggeringPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>[%date{yyyy-MM-dd HH:mm:ss.SSS zZ}] %-5level %msg %ex%n</Pattern> </layout> </appender> <appender name="Debug" class="ch.qos.logback.core.rolling.RollingFileAppender"> <bufferedIO>true</bufferedIO> <File>D:/temp/logtest/debug.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <FileNamePattern>D:/temp/logtest/debug.%i.log</FileNamePattern> <MinIndex>1</MinIndex> <MaxIndex>5</MaxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>20KB</MaxFileSize> </triggeringPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>[%date{yyyy-MM-dd HH:mm:ss.SSS zZ}] %-5level %msg %ex%n</Pattern> </layout> </appender> <root> <level value="trace" /> <appender-ref ref="Debug" /> </root> </configuration>
Missing error reporting if to appenders are configured with the same name -------------------------------------------------------------------------
Key: LBCORE-87 URL: http://jira.qos.ch/browse/LBCORE-87 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.13 Reporter: Michael Franz Assignee: Logback dev list
If two appenders within a joran configuration use the same name joran does not abort with an error. This may lead to not working system. An example that actually happend: An appender configuration for a RollingFileAppender with a FixedWindowRollingPolicy and a SizeBasedTriggeringPolicy was copied from one file into another, but the application included both files at once. Since all debug messages are to be written in this file it growed quite fast, but the system worked normally at first. But when rolling occurs the file could not be renamed (two file handles to the same file), so the rename by copy fallback started. After copying the deletion still failed. So the current log file is still over the rolling limit. As you might already can imaging, this happens from now on for all log messages to be written and makes the system almost only doing copying files. BTW.: The failure of the deletion of the current log file is also not reported as an error to the status manager.
-- 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
[ http://jira.qos.ch/browse/LBCORE-87?page=com.atlassian.jira.plugin.system.is... ] Michael Franz commented on LBCORE-87: ------------------------------------- Some things I forgot that might be of interest: Operating System: Windows XP Java: Sun 1.6.0_11-b03
Missing error reporting if to appenders are configured with the same name -------------------------------------------------------------------------
Key: LBCORE-87 URL: http://jira.qos.ch/browse/LBCORE-87 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.13 Reporter: Michael Franz Assignee: Logback dev list
If two appenders within a joran configuration use the same name joran does not abort with an error. This may lead to not working system. An example that actually happend: An appender configuration for a RollingFileAppender with a FixedWindowRollingPolicy and a SizeBasedTriggeringPolicy was copied from one file into another, but the application included both files at once. Since all debug messages are to be written in this file it growed quite fast, but the system worked normally at first. But when rolling occurs the file could not be renamed (two file handles to the same file), so the rename by copy fallback started. After copying the deletion still failed. So the current log file is still over the rolling limit. As you might already can imaging, this happens from now on for all log messages to be written and makes the system almost only doing copying files. BTW.: The failure of the deletion of the current log file is also not reported as an error to the status manager.
-- 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
participants (2)
-
Ceki Gulcu (JIRA) -
Michael Franz (JIRA)