Dan K commented on LOG4NET-551:

Awesome news!!! Thank you guys so much! I will go add it today via NuGet 
package and provide results! :)

> LockRecursionException when using File Appenders
> ------------------------------------------------
>                 Key: LOG4NET-551
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-551
>             Project: Log4net
>          Issue Type: Bug
>    Affects Versions: 2.0.7
>            Reporter: Matthew Lefoster
>            Priority: Minor
>             Fix For: 2.0.8
> I have been getting the following exception on the console:
> {quote}
> log4net:ERROR Exception while logging
> System.Threading.LockRecursionException: Recursive read lock acquisitions not 
> allowed in this mode.
>    at 
> System.Threading.ReaderWriterLockSlim.TryEnterReadLockCore(TimeoutTracker 
> timeout)
>    at System.Threading.ReaderWriterLockSlim.TryEnterReadLock(TimeoutTracker 
> timeout)
>    at System.Threading.ReaderWriterLockSlim.EnterReadLock()
>    at log4net.Util.ReaderWriterLock.AcquireReaderLock()
>    at log4net.Repository.Hierarchy.Logger.CallAppenders(LoggingEvent 
> loggingEvent)
>    at log4net.Repository.Hierarchy.Logger.ForcedLog(Type 
> callerStackBoundaryDeclaringType, Level level, Object message, Exception 
> exception)
>    at log4net.Repository.Hierarchy.Logger.Log(Type 
> callerStackBoundaryDeclaringType, Level level, Object message, Exception 
> exception)
> {quote}
> I have a number of different appenders, but this only happens when I am using 
> `log4net.Appender.FileAppender`.
> Using a debugger, I was able to narrow it down to this line (I replaced curly 
> brackets with square brackets because otherwise JIRA interprets them as 
> macros):
> {quote}
> Logger.DebugFormat("[1] Executing SQL: [0][2][0]With parameters: [3]",
>                 Environment.NewLine, methodName, sql, new 
> ToStringWrapper(parameters));
> {quote}
> My first thought was that ToStringWrapper() was throwing an exception or 
> generating another logging call. But If I put breakpoints at the log call and 
> at the first line of ToStringWrapper.ToString, the exception will show up in 
> the console between those two points.
> Oddly enough, if I "step into" the logging call instead of just "continuing" 
> and letting the breakpoints handle it, no exception happens.

This message was sent by Atlassian JIRA

Reply via email to