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]. >> [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 apply? >> 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 1.2.13.0 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 1.2.11.0 so was going to use the following approach. Update to 1.2.13.0 Add this to web.config to redirect to 1.2.13.0 <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a"/> <bindingRedirect oldVersion="0.0.0.0-1.2.13.0" newVersion="1.2.13.0"/> </dependentAssembly> </assemblyBinding> </runtime>
