Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-2658

Exceptions during compacting in the context of RollingFileAppender are not logged

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.1, 2.12.0
    • Fix Version/s: 2.12.1
    • Component/s: Appenders
    • Labels:
      None

      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.

        Attachments

          Activity

            People

            • Assignee:
              ckozak Carter Kozak
              Reporter:
              Christopher Roscoe Christopher Roscoe
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 40m
                40m