[jira] [Created] (LOG4J2-2658) Exceptions during compacting in the context of RollingFileAppender are not logged

["Christopher Roscoe (JIRA)" <ji...@apache.org>]

Christopher Roscoe created LOG4J2-2658:
------------------------------------------

             Summary: Exceptions during compacting in the context of RollingFileAppender are not logged
                 Key: LOG4J2-2658
                 URL: https://issues.apache.org/jira/browse/LOG4J2-2658
             Project: Log4j 2
          Issue Type: Bug
          Components: Appenders
    Affects Versions: 2.8.1
            Reporter: Christopher Roscoe


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.

{code}
        <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>
{code}

 
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.

{code}
asyncExecutor.execute(new AsyncAction(descriptor.getAsynchronous(), this));
{code}

The top level method org.apache.logging.log4j.core.appender.rolling.action.AbstractAction.run() catches IOExceptions as expected.

{code}
 try {
     execute();
 } catch (final IOException ex) {
     reportException(ex);
 }
 {code}

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.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)