logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Scott" <jsc...@infoconex.com>
Subject Re: IIS Deadlocks happening all the sudden after years of running with no issues
Date Mon, 22 May 2017 21:54:35 GMT

From: Dominik Psenner 
Sent: Monday, May 22, 2017 1:27 PM

   >> Please note that it is known that an application can also cause log4net to deadlock
  >> [3] https://issues.apache.org/jira/browse/LOG4NET-298

  This particular application is not using any async/task code so not sure if other scenarios

>> That's not true. All it needs is two threads and the well known dead lock candidates
(waits, locks, ..). Does your web application pass objects on to the logging framework or
are all >> arguments converted to immutable types (string, int, bool, ..)? If the logging
framework calls ToString() of an object, beware!

I will have to do some investigating to see. However I know we log exceptions using log.Error(“Exception
details”, ex) and it seems that every time this issue occurs it is happening while attempt
to write an exception to the exception.log we have configured. Note that according to the
stack trace it appears that the exceptions log is attempting to be rolled when the issue happens.
I can also see now that our exceptions log is intermittently getting rolled whereas the other
logs seem to be rolling as expected. One thing different about this logging configuration
for exceptions is that we are using MinimalLock so that the file can be cleared.

  We have also installed Debug Diagnostics on the machine to take memory dumps and analyze
the results and this made it really easy to determine the deadlock issue and provide the traces
previously. If you have any suggestions for further diagnosing it would be appreciated. Was
thinking that maybe I would have enabled log4net debugging?

>> That's a great starting point. Maybe something fishy jumps out that makes it easier.
You could further investigate the behavior of your web application when the dead lock happened.

What suggestions might you have with regards to investigating the behavior of the web application
when the deadlock happened?

>> Please note also that 1.2.11 is from 2011 and rather old. Can you give a newer log4net
version a shot?

That was my next move actually. We use on a few other projects and since we have
been using reliably in those applications was going to see if moving to it made any difference.
This project has a number of dependencies that are all compiled again so was going
to use the following approach.

Update to
Add this to web.config to redirect to
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">      
            <assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a"/>
            <bindingRedirect oldVersion="" newVersion=""/>

View raw message