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

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902427#comment-16902427 ] 

ASF subversion and git services commented on LOG4J2-2658:
---------------------------------------------------------

Commit e5503d7f9f0f8059c1c83e028a54ec7d84ea112c in logging-log4j2's branch refs/heads/release-2.x from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e5503d7 ]

[LOG4J2-2658] Make test OS independent.

> 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, 2.12.0
>            Reporter: Christopher Roscoe
>            Assignee: Carter Kozak
>            Priority: Major
>             Fix For: 2.12.1
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> 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)