[
https://issues.apache.org/jira/browse/LOG4NET-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15896931#comment-15896931
]
Dan K edited comment on LOG4NET-551 at 3/6/17 9:05 AM:
-------------------------------------------------------
Stefan, that doesn't seem very reasonable. Especially, given any time this
particular exception occurs, log event/messages are completely lost. That is
completely unacceptable in a production setting. I would think at the very
least, now that this issue has been made aware of, some sort of hot fix/patch
for v2.0.7 become "officially" available if v2.0.8 has to wait. If I recall
correctly, one minor bug found in v2.0.6 triggered an immediate fix/release
through NuGet and made available that same week (v2.0.7). Why would something
as important as this be handled any different? Again, the alternative hacks
mentioned in this thread aren't a viable option.
was (Author: dklausne...@gmail.com):
Stefan, that doesn't seem very reasonable. Especially, given any time this
particular exception occurs, log event/messages are completely lost. That is
completely unacceptable in a production setting. I would think at the very
least, now that this issue has been made aware of, some sort of hot fix/patch
for v2.0.7 become "officially" available if v2.0.8 has to wait. If I recall
correctly, one minor bug found in v2.0.6 triggered an immediate fix/release
through NuGet and made available that same week. Why would something as
important as this be handled any different? Again, the alternative hacks
mentioned in this thread aren't a viable option for us. I'm sure other's in the
same boat whom are using v2.0.7, won't be happy either. Just because log4net
fails "silently" I wouldn't think that translates to prolonging releases.
> 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)
