Matthew Hill commented on LOG4J2-2061:

Hi [~garydgregory]

Has there been any progress on this issue?

> 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
>            Assignee: Ralph Goers
>            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

Reply via email to