[ https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ralph Goers resolved LOG4J2-2061. --------------------------------- Resolution: Fixed Fix Version/s: 2.11.2 I incorporated the unit test you provided and it now passes. Please verify and close. > 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 > Fix For: 2.11.2 > > 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 (v7.6.3#76005)