Commit access requested for an asynchronous logging addition

[Jason Aubrey <ja...@connamara.com>]

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

Re: Commit access requested for an asynchronous logging addition

[Jason Aubrey <ja...@connamara.com>]

Hi Ron,

I've opened a JIRA ticket: https://issues.apache.org/jira/browse/LOG4NET-201

Thanks for the input, I added our e-mails and replies in the ticket.

Jason

Re: Commit access requested for an asynchronous logging addition

[Ron Grabowski <ro...@yahoo.com>]

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 <ja...@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