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 16:38:09 GMT


Thank you for your reply. 

>> please don't expect a sensible response within hours, especially with such a complex

No problem, I looked at the archive and noticed I was the only post this month so was thinking
that maybe a newer list existed.

>> :-) At first sight, if it did run for over two years and suddenly keeps crashing
on a daily basis it is 
>> very unlikely that something that was not modified is the actual culprit. 

I agree, nothing in the application has changed as I can see all of the dates of the files
are from the last deployment in Nov 2015. 

>> Did any modifications happen lately that you are aware of?

The only thing I can see is that the box has been getting regular windows updates which of
course includes .NET and OS updates. Could it be that something in the framework has changed
behavior of something that is now creating this issue?

>> Please note that IIS has some interesting default behavior, it would for instance
start a new instance of a site before the old site is destroyed. 
>> This means that multiple instances of the same site use the same configuration and
are therefore going to log and roll into the same files. 
>> This is well known [1][2] and has been raised as an issue several times on this list.
>> The symptoms you see sound very much like that, but note that this is just a guess.

>> [1] https://www.google.it/search?q=log4net+iis+deadlock&oq=log4net+iis+deadlock
>> [2] http://hectorcorrea.com/blog/log4net-thread-safe-but-not-process-safe/17

Yes, I read that article [2] I had our operations group modify IIS set “Disable Overlapped
Recycle” to true. We are also only running 1 worker process so nothing in our install applies
to the web garden scenario. Note that I figured this might be the culprit but we have had
the same deadlock happen after this change.

>> 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

>> Further there is also this issue [4].
>> [4] https://issues.apache.org/jira/browse/LOG4NET-178

We are not seeing an issue with logging stopping and we also changed our app pool recycle
to a specific time rather than the default of 1720 minutes. When we have had our deadlock
issue it has not been during an app pool recycle (unless IIS was trying to kick the process
for other reasons, although nothing in event viewer indicating something was trying to recycle).
Anything in this particular bug that you think I might want to look at that still might be
related even though the symptom is not the same?

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?
View raw message