You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2019/07/19 16:33:00 UTC

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

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

ASF GitHub Bot logged work on LOG4J2-2658:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 19/Jul/19 16:32
            Start Date: 19/Jul/19 16:32
    Worklog Time Spent: 10m 
      Work Description: carterkozak commented on pull request #293: LOG4J2-2658: AbstractAction.reportException records a warning to the status logger
URL: https://github.com/apache/logging-log4j2/pull/293
 
 
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 279822)
            Time Spent: 10m
    Remaining Estimate: 0h

> 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
>            Assignee: Carter Kozak
>            Priority: Major
>          Time Spent: 10m
>  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)