[
https://issues.apache.org/jira/browse/LOG4NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600904#action_12600904
]
Strategic Insurance Software commented on LOG4NET-158:
------------------------------------------------------
Ron Grabowski said:
"Have you had a chance to test my solution to your log4net issue?"
I'm just now for the first time looking at the source to XmlConfigurator. I've
not had a chance to test the proposed fix specifically, and I'm not an expert
on this source code, but unless I'm missing something, this would not fix the
issue, as OnWatchedFileChange would only be called if the configuration file
actually changes, and would not be called when a second/third/nth
FileSystemWatcher is created.
The following might be a possible fix based on my reading of the code:
1. Establish an instance variable within the ConfigureAndWatchHandler class to
hold a reference to the created FileSystemWatcher.
2. Implement the IDisposable interface/pattern on the ConfigureAndWatchHandler
class. Within its implementation of Dispose, call the FileSystemWatcher's
Dispose() method.
3. Establish a static variable in XmlConfigurator to hold a reference to the
ConfigureAndWatchHandler that is created in ConfigureAndWatch().
4. In ConfigureAndWatch, add code prior to the creation of the
ConfigureAndWatchHandler to call .Dispose() for the previously created
ConfigureAndWatchHandler, if one was created previously.
Ron Grabowski said:
"How did you detect the file handler lock?"
To clarify, we're talking about file handles, not locks. We have a series of
server applications (ASP.NET web service, plus supporting Windows Services),
and while we have been leveraging log4net for a while, our recent release made
much more extensive use of logging. The apps would leak to the point of
needing to be restarted several times daily. We used the sysinternals tools to
nail down that we were leaking file handles, and found that all of the leaked
handles were pointing to the folder containing our log4net configuration file.
Upon further investigation, we found that we were calling
XmlConfiguration.ConfigureAndWatch() every time we created an instance of our
internal logging class, which wraps our access to log4net. We changed our app
to only call ConfigureAndWatch() once, and our leak went away.
Ron Grabowski said:
"What use case to have for calling ConfigureAndWatch multiple times? Its
usually only called once when the application starts."
It's true enough that we should have only been calling this method once, and
our code has been corrected to reflect that. We've effectively worked around
the issue, but I still wanted to report it so that in future releases, multiple
calls to ConfigureAndWatch() would be more harmless (aside from the obvious
performance implications).
> XMLConfigurator.ConfigureAndWatch() leaks resources if called multiple times
> ----------------------------------------------------------------------------
>
> Key: LOG4NET-158
> URL: https://issues.apache.org/jira/browse/LOG4NET-158
> Project: Log4net
> Issue Type: Bug
> Components: Other
> Affects Versions: 1.2.10
> Environment: Windows Server 2003, Windows XP
> Reporter: Strategic Insurance Software
>
> If XMLConfigurator.ConfigureAndWatch() is called multiple times within an
> AppDomain, each time it is called it leaks a Win32 file handle (possibly
> from a FileSystemWatcher object not being disposed?) to the folder containing
> the previous configuration file it was watching.
> Desired behavior would be to release the handle to the folder containing the
> previous configuration file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
