logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject Re: Commit access requested for an asynchronous logging addition
Date Wed, 18 Feb 2009 05:05:27 GMT
The best place to put your code would be on a new JIRA ticket and make sure to grant the ok
to include into a ASF project.

I've been thinking about a feature like this but I wanted to get the remaining tickets for
the next version closed out (before 4.0 comes out!!!). My original plan was to Fix the events
then dispatch them to another worker thread as soon as they arrived so the code would return
to the caller as soon as possible. I was thinking more on the ILoggerRepository (Hiearchy)
level as opposed to an individual Logger. The Logger level definietly offers more control
but part of me things that people would be ok with either all loggers being sync (how it is
today) or all-async...allowing them to change on a per Logger level might be too confusing
??? Plus if there's a Thread per Logger and there are a lot of Loggers won't
there be a lot of Threads running? I suppose that's why you added a
property on a per logger basis to control which specific loggers were
async.

ThreadSafeBlockingQueue.Dequeue(Queue) could dequeue the items into LoggingEvent[] to allow
IBulkAppenders to better handle the items.

When ForcedLogSub is called with FixFlags.All I think a StackTrace is capture (slow) even
if none of the attached appenders use location information. Maybe add some checks to AddAppender
to make a FixFlags that is All - LocationInfo.

Its late, I have another solution that I'll write about tomorrow.



________________________________
From: Jason Aubrey <jaubrey@connamara.com>
To: log4net-dev@logging.apache.org
Sent: Tuesday, February 17, 2009 12:13:26 PM
Subject: Commit access requested for an asynchronous logging addition

Hi,

I just added a property to my working copy called 'Synchronous'.  It's 'true' by default to
maintain the current behavior.  When 'false' the logger will queue log events in a thread
safe queue that's serviced by a worker thread.  

The goal of asynchronous logging is to reduce the amount of time incurred by logging on the
primary thread.  This can be useful in applications such as in financial trading where time
is quite literally money.  It's realized that a data integrity risk is introduced by logging
asynchronously, but this is a known and acceptable risk.  I added the synchronous option within
the logger instead of the appenders because the behavior should apply to all appenders.

The new/modified files are attached within log4net_trunk.zip.  I don't currently have commit
access but I can commit the code if granted access.  There are unit tests for the new code.

Jason Aubrey

Mime
View raw message