logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan K (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4NET-551) LockRecursionException when using File Appenders
Date Mon, 06 Mar 2017 13:25:33 GMT

    [ 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:25 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 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. 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: dklausner75@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 occuring, and sure enough we see this one. Others
probably haven't reported it because they aren't enabling internal debugging/trace listeners.
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)

Mime
View raw message