Yuvraj, Did you try setting a breakpoint on the FileSystemWatcher constructor and seeiing what in log4net is calling it? Also, how much threading and/or appdomain creation is happening in your app? Are you using a RollingLog appender, and if so are multipel log fiels with a GUID prepended being created in the log folder?
Justin On Fri, May 24, 2013 at 2:27 AM, Dominik Psenner <[email protected]> wrote: > Good morning Yuvraj,**** > > ** ** > > There’s no way of being sure unless you have tried it out with your > application or a sample application that uses log4net in the same way you > do. Of course a sample application could do things faster than normal and > in an automated way so that the problem happens sooner and not only after 3 > months. J**** > > ** ** > > So my testing setup would be two identical virtual machines. The first > runs the application against 1.2.10 and the second runs the application > against 1.2.11. This way you can expect to see:**** > > ** ** > > **· **Virtual machine #1 leaks memory**** > > **· **Virtual machine #2 either does or doesn’t leak memory**** > > ** ** > > Cheers**** > > ** ** > > *Von:* Yuvraj Raj [mailto:[email protected]] > *Gesendet:* Donnerstag, 23. Mai 2013 20:27 > *An:* [email protected] > *Betreff:* log4net.dll version 1.2.10.0 (FileSystemWatcher objects)**** > > ** ** > > Hi,**** > > ** ** > > I am application developer team supporting.NET project in Michaels Stores. > We have been using log4net.dll version *1.2.10.0* for application logs > for our project. The application is implemented in .NET , C# with 3.5 > framework.**** > > ** ** > > Recently we have faced System.OutOfMemoryException exception thrown by the > application. We have opened case with Microsoft. Microsoft analyzed and > said memory consumption is due to *FileSystemWatcher* objects used by * > log4net.Config.XmlConfigurator+ConfigureAndWatchHandler* which are still > alive and pinned objects.**** > > ** ** > > From the memory dump, They found >2000 instances of * > log4net.Config.XmlConfigurator+ConfigureAndWatchHandler* and the * > FileSystemWatcher* objects created that contributed this issue. The issue > is happening due to the fragmentation of Gen2 Heap. The reason for the > fragmentation is the pinned System.IO.Overlapped objects used by * > FileSystemWatcher* objects.**** > > ** ** > > To resolve the memory issue, we need to get rid of the fragmentation > caused by pinned objects used by *FileSystemWatcher* objects**** > > ** ** > > We have created logger object in singleton class but not sure how multiple > objects are being created.**** > > ** ** > > When looking at the log4net.dll help from Apache web page, we found the > below link for log4net that have bug (LOG4NET-158) in version 1.2.10.0 > saying XmlConfigurator.ConfigureAndWatch() leaks resources if called > multiple times**** > > ** ** > > > https://issues.apache.org/jira/browse/LOG4NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601148#action_12601148 > **** > > ** ** > > The issue was fixed in version 1.2.11.0. Please let us know if above > memory issue was related to the bug and it has been resolved in the next > release. **** > > ** ** > > Any help would be greatly appreciated.**** > > ** ** > > ** ** > > ** ** > > Best Regards,**** > > Yuvraj**** > > Work: 972 409 5703 | Support: 972 400 0174 | Cell: 469 438 1396**** > > ** ** > > > > _____________________________________________________________________________ > Scanned by IBM Email Security Management Services powered by MessageLabs. > For more information please visit > http://www-935.ibm.com/services/us/index.wss/offerfamily/iss/a1026954 > > _____________________________________________________________________________ > **** >
