A log event might be badly programmed and recursive by definition. Think of two
objects that try each to log while trying to format each other:
A {
DoWork() {
Log(“A: {0}”, B)
}
}
B {
DoWork () {
Log(“B: {0}”, A)
}
}
I might be wrong, but something like that does the recursive guard detect and
resolve.
For the other question you’ll have to accept my apologies because I can’t
answer the question „how to write code“. :)
Von: Gert Kello [mailto:[email protected]]
Gesendet: Mittwoch, 04. März 2015 15:16
An: Log4NET User
Betreff: Re: AppenderSkeletion lock in DoAppend
But what about this m_recursiveGuard? Is the recursion protection needed?
Perhaps it is, if log saving code logs something by itself? (Like warning that
database operation takes longer than expected)?
Well, as I plan to make the database saving asyn I need to tackle this problem
anyway... I think I would like to log the performance problem. But not when the
problem occurs during saving log about the same performance problem. Is there
any guideline how to write such code? Something like using OnlyOnceErrorHandler
or is there anything similar for warnings?
Gert
On 4 March 2015 at 15:38, Dominik Psenner <[email protected]
<mailto:[email protected]> > wrote:
Hi,
from what I can recall it could happen that the formatted representation of a
logging event gets mixed up with data from other events and thus the characters
streamed to a sink become garbage (i.e. a file, console, ..) if this lock is
removed.
Internally a lot of things are cached to improve performance and these caches
actually require proper locking.
But my memory might be wrong, so feel free to remove the lock and let several
threads log events to your appender to see if it can handle it properly. :)
Cheers
Von: Gert Kello [mailto:[email protected] <mailto:[email protected]> ]
Gesendet: Mittwoch, 04. März 2015 09:28
An: [email protected] <mailto:[email protected]>
Betreff: AppenderSkeletion lock in DoAppend
Hi.
I'm trying to create a database appender which high throughput... I looked at
code in AppenderSekeletion.DoAppend() method and saw following comment:
public void DoAppend(LoggingEvent loggingEvent)
{
// This lock is absolutely critical for correct formatting
// of the message in a multi-threaded environment. Without
// this, the message may be broken up into elements from
// multiple thread contexts (like get the wrong thread ID).
lock (this)
{
I would like to remove this lock from my code but there's a couple of issues I
do not understand:
1. As I do not know the internals of log4net well enough I do not understand
why lock is important for message formatting? Is it because the Layout.Format
is not supposed to be thread safe? Or is it because the same instance of
m_renderWriter could be used by multiple threads (well, usage of m_renderWriter
is protected by another lock, added later. But AFAIK the
RenderLoggingEvent(LoggingEvent loggingEvent) is still not 100% thread safe)
2. The comment does not mention that lock is crucial for m_recursiveGuard to
work correctly. That's my main complaint: I almost overlooked the issue of
potentially skipped logging events.
3. What about implementations of IFilter.Decide? Are those (supposed to be)
thread safe?
Gert
