2017-05-22 23:54 GMT+02:00 Jim Scott <jsc...@infoconex.com>: > > > *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. >
Put this on the list of possible causes. I would rather always go with FileAppender.ExclusiveLock <http://logging.apache.org/log4net/log4net-1.2.12/release/sdk/log4net.Appender.FileAppender.ExclusiveLock.html>, also from a performance point of view. I observed a speedup factor that is often beyond 20. > > >> >> >> 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? > Looks like you already figured out something I was referring to. Often it is enough to know what the users did to track down what an application should do (and possibly should but does not). After all it boils down to a few scenarios and that helps a lot, just like you pointed out the MinimalLock for exceptions. > > >> 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> > > I did not know this was even possible. :-) The api should still be the same, so there should be no obstacles unless one dependency uses the strong name assembly. Then it should (to my knowledge) accept only the one it was linked against. -- Dominik Psenner
