[
https://issues.apache.org/jira/browse/LOG4NET-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897000#comment-15897000
]
Dan K edited comment on LOG4NET-551 at 3/6/17 1:35 PM:
-------------------------------------------------------
Upgrading should be a good thing, which is why we didn't mind going to v2.0.7
initially. Log4net is our go-to for both file logging/db logging and as part of
testing procedure after upgrade, report any "silent" exceptions/degrades. As a
result, we started seeing this exception consistently and noticed it's isolated
when file appender is used. We notice a huge difference between messages
writtent to DB (more) vs to file because of these exceptions and file logging
losing messages. Others probably haven't reported it because they aren't
enabling internal debugging/trace listeners or don't have DB/File logging
capabilities to compare that something is wrong. I will post the exception we
see as well here to further uphold our findings and perhaps help others that
experience same thing. I can build the dependency from trunk just to verify the
fix addresses it, but we see that when the appender is called that it can't
recursively log when using the default policy in .net 4.0/above, which the fix
in v2.0.8 addresses.
was (Author: dklausne...@gmail.com):
Upgrading should be a good thing, which is why we didn't mind going to v2.0.7
initially. Log4net is our go-to for both file logging/db logging and as part of
our normal testing after upgrade, to see if there were any "silent"
exceptions/degrades. As a result, we started seeing this exception consistently
and noticed it's isolated to file logging when file appender is used. We notice
a huge difference between messages writtent to DB (more) vs to file because of
these exceptions and file logging losing messages. Others probably haven't
reported it because they aren't enabling internal debugging/trace listeners or
don't have DB/File logging capabilities to compare that something is wrong. I
will post the exception we see as well here to further uphold our findings and
perhaps help others that experience same thing. I can build the dependency from
trunk just to verify the fix addresses it, but we see that when the appender is
called that it can't recursively log when using the default policy in .net
4.0/above, which the fix in v2.0.8 addresses.
> 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)
