[
https://issues.apache.org/jira/browse/LOG4NET-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897243#comment-15897243
]
Dan K edited comment on LOG4NET-551 at 3/6/17 1:19 PM:
-------------------------------------------------------
Hi Stefan, here is a little more background/detail/context with issue we are
currently seeing in v2.0.7:
1) During latest development cycle, we upgraded straight from version 1.2.11 to
v2.0.6, then the same week to v2.0.7 with intent to use the latest version for
upcoming release. As you are aware, there have many bugs fixed/improvements
made since 1.2.11. Then we could have addressed this sooner.
2) We didn't see this exception until the upgrade to v2.0.7. We wouldn't have
known about this error prior since it wasn't present in 1.2.11, which is
consistent with your last comment. I wasn't involved in the logging development
efforts during that time and not sure why this wasn't upgraded sooner.
3: Here is the consistent/only exception we see with log4net internal debugging
on using v2.0.7:
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 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)
4. With all the evidence we have so far around this particular exception, we
strongly feel that the fix in v2.0.8 will help us get past this block and move
forward.
was (Author: dklausne...@gmail.com):
Hi Stefan, here is a little more background/detail/context with issue we are
currently seeing in v2.0.7:
1) During latest development cycle, we upgraded straight from version 1.2.11 to
v2.0.6, then the same week to v2.0.7 with intent to use the latest version for
upcoming release. As you are aware, there have many bugs fixed/improvements
made since 1.2.11.
2) We didn't see this exception until the upgrade to v2.0.7. We wouldn't have
known about this error prior since it wasn't present in 1.2.11, which is
consistent with your last comment. I wasn't involved in the logging development
efforts during that time and not sure why this wasn't upgraded sooner.
3: Here is the consistent/only exception we see with log4net internal debugging
on using v2.0.7:
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 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)
> 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
(v6.3.15#6346)
