[
https://issues.apache.org/jira/browse/LOG4NET-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899209#comment-15899209
]
Dan K edited comment on LOG4NET-551 at 3/7/17 2:21 PM:
-------------------------------------------------------
Hi Stefan,
Update:
1) I cloned and built v2.0.8 from latest trunk to upgrade as you suggested.
In our case, this is will be for testing purposes only until we get an
official release through NuGet.
2) Running a new build of our own software using v2.0.8 since yesterday
morning and no more "LockRecursionExceptions". We usually see these
immediately with v2.0.7, but wanted to run all day/overnight under heavy
load just to make our case.
Please let me know if there is anything else you would like us to try to
help expedite official release of v2.0.8. We understand/respect this is
open source and the process for releases is different, but your help to
make this happen is very much appreciated. I am sure others will appreciate
this release too as they learn their version could be "silently" throwing this
particular exception since version 1.2.12.
On Mar 6, 2017 6:11 AM, "Stefan Bodewig (JIRA)" <j...@apache.org> wrote:
[ https://issues.apache.org/jira/browse/LOG4NET-551?page=com.
atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
l&focusedCommentId=15897107#comment-15897107 ]
Stefan Bodewig commented on LOG4NET-551:
----------------------------------------
anything that ensures the release will actually fix the problem for you
will be good.
This issue must have been present since 1.2.12.
not allowed in this mode.
timeout)
timeout)
loggingEvent)
callerStackBoundaryDeclaringType, Level level, Object message, Exception
exception)
callerStackBoundaryDeclaringType, Level level, Object message, Exception
exception)
using `log4net.Appender.FileAppender`.
curly brackets with square brackets because otherwise JIRA interprets them
as macros):
ToStringWrapper(parameters));
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.
"continuing" and letting the breakpoints handle it, no exception happens.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
was (Author: dklausne...@gmail.com):
Hi Stefan,
Update:
1) I cloned and built v2.0.8 from latest trunk to upgrade as you suggested.
In our case, this is will be for testing purposes only until we get an
official release through NuGet.
2) Running a new build of our own software using v2.0.8 since yesterday
morning and no more "LockRecursionExceptions". We usually see these
immediately with v2.0.7, but wanted to run all day/overnight under heavy
load just to make our case.
Please let me know if there is anything else you would like us to try to
help expedite official release of v2.0.8. We understand/respect this is
open source and the process for releases is different, but your help to
make this happen is very much appreciated.
On Mar 6, 2017 6:11 AM, "Stefan Bodewig (JIRA)" <j...@apache.org> wrote:
[ https://issues.apache.org/jira/browse/LOG4NET-551?page=com.
atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
l&focusedCommentId=15897107#comment-15897107 ]
Stefan Bodewig commented on LOG4NET-551:
----------------------------------------
anything that ensures the release will actually fix the problem for you
will be good.
This issue must have been present since 1.2.12.
not allowed in this mode.
timeout)
timeout)
loggingEvent)
callerStackBoundaryDeclaringType, Level level, Object message, Exception
exception)
callerStackBoundaryDeclaringType, Level level, Object message, Exception
exception)
using `log4net.Appender.FileAppender`.
curly brackets with square brackets because otherwise JIRA interprets them
as macros):
ToStringWrapper(parameters));
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.
"continuing" and letting the breakpoints handle it, no exception happens.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
> 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)
