logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominik Psenner" <dpsen...@gmail.com>
Subject RE: Async logging
Date Fri, 08 Jun 2012 07:36:50 GMT
Hi Christian,

thanks for the feedback.

>> ·         the ThreadPool should be used in favour over a designated
>worker
>> Thread
>
>no idea becuase I have no clue on .NET, but it sounds like fun :-)

It just means that it is not written as:

new Thread(() => { ..; Thread.Sleep(x); }

but rather there is only a worker thread active when there are pending log
events. The algorithm is quite simple:

Append(logEvent) {
 Queue.append(logEvent)
 If(queue.size == 1) {
  Threadpool.Invoke(ForwardMessages)
 }
}

ForwardMessages() {
 While(Queue.count > 0){
  # forward
 }
}

Of course it needs some locking and other dark magic in between to work as
expected.

>> ·         if the queue is full, it should fallback to synchronous
>logging,
>> shouldn’t it?
>
>Not sure on this: this would probably impact the application in terms
>of performance right?

Yes. But it does in a "safer" manner. The philosophy is much like safer sex.
Either strategy means:

case Strategy.IGNORE:
 RAM caching => OutOfMemoryException
case Strategy.DISMISS:
 loss of events, I'm not a great fan of this
case Strategy.SYNC:
 the calling application is slowed down approximately to how fast the log
events can be serialized to the underlying I/O, which means the async
implementation behaves more like a buffer

>Probably this should be configurable to:
>
>QUEUE_OVERFLOW_STRATEGY=DISMISS -> throws away the log events
>QUEUE_OVERFLOW_STRATEGY=SYNC -> goes back to synchronized logging

Good point. And for brave developers:
QUEUE_OVERFLOW_STRATEGY=IGNORE -> ignores queue overflow

>In either case, a warning message should be generated.

Of course. But we should make sure to not stress the CPU with too many
additional warnings since it probably would be already at its limits.

>Another interesting feature would  to set a threshhold for the queue.
>Lets assume it is 100, and 100 messages are in the queue while 150 are
>allowed, one could get a warning log that the threshhold of 100 is
>passed.

Is it really required to make that configurable? If so, I would make it an
optional configuration with the fallback to something like
THRESHOLD=MAX_QUEUE_SIZE*0.9 that outputs warnings whenever the queue size
hits a multiple of TRESHOLD (i.e. queue.size % TRESHOLD == 0).

>
>> ·         queued log events should be processed when the appender gets
>> disposed
>
>+1

The problem here is that the CLR may take over (i.e. on crashes) and simply
terminate the appender together with the assembly that loaded it. Does
somebody know a way to preserve the last few log messages from destruction
in those corner cases?


Mime
View raw message