logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Hill (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-2061) RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy
Date Wed, 11 Oct 2017 13:11:00 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Matthew Hill updated LOG4J2-2061:
    Attachment: Log4jIssue.zip

> RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy
> -----------------------------------------------------------------------------------------------------
>                 Key: LOG4J2-2061
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2061
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.9.0
>         Environment: *
>            Reporter: Matthew Hill
>            Priority: Blocker
>         Attachments: Log4jIssue.zip
> When programmatically creating an instance of RollingFileAppender using RollingFileAppender.newBuilder.(config
options).build(), an instance of RollingFileManager is created in AbstractManager.getManager(...),
and this instance is stored in the hashmap AbstractManager.MAP as well as on the instance
of RollingFileAppender in the super class AbstractOutputStreamAppender. This manager is created
and stored in the AbstractManager.MAP with the name FILE_PATTERN (since we cannot create an
instance of RollingFileAppender with a file name using the DirectWriteRolloverStrategy). However,
the same manager is created with a NAME of NULL since it is trying to use file name as the
name of the manager, but this parameter is not allowed using DirectWriteRolloverStrategy.

> The problem here is that the RollingFileManager is created with a name of FILE NAME (i.e.,
NULL when using DirectWriteRolloverStrategy) and added to the hashmap with a key of FILE PATTERN,
but when the rolling file appender is stopped, it attempts to remove its manager from this
MAP using RollingFileManager.name, which equates to FILE NAME which is NULL.
> Consider the following example:
> * create a rolling file appender using the DirectWriteRolloverStrategy with a file pattern
of 'output.%i.log'
> * a RollingFileManager is created with the name NULL, but put in AbstractManager.MAP
with the name 'output.%i.log'
> * the rolling file appender is used to write a few line of log file
> * the rolling file appender is stopped using RollingFileAppender.stop(..)
> * the RollingFileManager is NOT removed from AbstractManager.MAP since it is trying to
remove FILE NAME but it is keyed on FILE PATTERN
> * a NEW instance of rolling file appender is created using the DirectWriteRolloverStrategy
with the SAME file pattern of 'output.%i.log'. 
> * a new instance of RollingFileManager is NOT created, as it already exists in the MAP,
so the old instance is simply returned
> * the instance of RollingFileManager for the new instance of RollingFileAppender has
a closed output stream, meaning that no logging is possible.
> In the above example you can see that if the old rolling file appender's output stream
is closed, and a new instance created with the same file pattern, then the old manager will
be used. I see no easy way of recreating this output stream.
> I found no documentation regarding why one cannot set the FILE NAME for a RollingFileAppender
using DirectWriteRolloverStrategy. Being able to configure this may also solve the problem
(unless it causes issues elsewhere), but another possible fix to this issue is to create the
RollingFileManager with the name FILE PATTERN when using the DirectWriteRolloverStrategy.
This way we add to the MAP the instance of RollingFileManager with the key FILE PATTERN, and
we remove from the MAP RollingFileManager.name which equals FILE PATTERN

This message was sent by Atlassian JIRA

View raw message