Major Description
My customer reported that the log files of my application were consuming too much disc space. After some analysis i found out that the compacting to zip files was not applied. I need to find out why, but i am missing the needed error diagnosis messages.
I use a RollingFileAppender with following configuration.
<RollingFile name="RollingFile" fileName="${sys:logPath}/application.log" filePattern="${sys:logPath}/application-%d\{yyyy-MM-dd}-%i.log.zip"> <PatternLayout pattern="%d\{YYYY-MM-dd HH:mm:ss.SSS 'UTC'XXX} [host=%X\{hostName};user=%X\{userName}] [%t] %-5level %logger\{36} - %msg%n" /> <Policies> <TimeBasedTriggeringPolicy /> <SizeBasedTriggeringPolicy size="50 MB" /> </Policies> <DefaultRolloverStrategy max="50"> <Delete basePath="${sys:logPath}/"> <IfFileName regex="application-\d.*(\.log\.zip|\.log)" /> <IfLastModified age="10d" /> </Delete> </DefaultRolloverStrategy> </RollingFile> <Async name="File"> <AppenderRef ref="RollingFile" /> </Async>
Apart from the zip compression everything else works.
I made some effort to reproduce the issue on my machine with debugging enabled.
I found out that org.apache.logging.log4j.core.appender.rolling.action.ZipCompressAction is responsible for doing the actual zip compressing. At this point something could go wrong and an exception would be raised. But as far as i comprehend the code this exception is not handled appropriate.
The org.apache.logging.log4j.core.appender.rolling.RollingFileManager executed this action during the rollover in some asyncExecutor. The actions are wrapped in the inner class RollingFileManager$AsyncAction.
asyncExecutor.execute(new AsyncAction(descriptor.getAsynchronous(), this));
The top level method org.apache.logging.log4j.core.appender.rolling.action.AbstractAction.run() catches IOExceptions as expected.
try { execute(); } catch (final IOException ex) { reportException(ex); }
RollingFileManager$AsyncAction does not override the method reportException(Exception) and in AbstractAction the implementation is empty.
This leads me to assume that any IOException during zip compacting in the context of RollingFileAppender is silently ignored.
I would expect that such Exception is reported and logged on WARN or ERROR level.
