[
https://issues.apache.org/jira/browse/LOG4J2-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-2658.
--------------------------------
Verified by [~Christopher Roscoe] on 2.12.1-SNAPSHOT.
> 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)
