[
https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200248#comment-16200248
]
Matthew Hill commented on LOG4J2-2061:
--------------------------------------
Hi [~garydgregory]
Please see attached a sample junit that shows the issue. The comments within
the junit show what is expected and what actually happens.
Regards
Matthew
> 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
(v6.4.14#64029)
