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:gert.ke...@gmail.com] Gesendet: Mittwoch, 04. März 2015 09:28 An: log4net-user@logging.apache.org 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
