[jira] Updated: (LOG4NET-201) Add asynchronous logging behavior

["Jason (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOG4NET-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason updated LOG4NET-201:
--------------------------

    Attachment: log4net_trunk.zip

This is the file I attached to my original e-mail.  However, this file contains changes made while naive about the overall structure of log4net.  Ron's subsequent e-mail makes some good suggestions for improvement.  This could however be a starting point, or a source for copy and paste (e.g. the ThreadSafeBlockingQueue).

> Add asynchronous logging behavior
> ---------------------------------
>
>                 Key: LOG4NET-201
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-201
>             Project: Log4net
>          Issue Type: New Feature
>          Components: Core
>         Environment: All
>            Reporter: Jason
>         Attachments: log4net_trunk.zip
>
>
> This issue was first discussed in an e-mail conversation which I'll paste here:
> -------------------------------------------------
> Hi Ron,
> I'll open a JIRA ticket for this issue.  
> I've only looked at log4net briefly (an hour before I started coding - needed a quick solution), so I'm happy to hear your input.  
> My less knowledgeable inputs:
> * For the hierarchy level vs the logger level, I agree that the hierarchy level seems better.  I didn't realize anything about the 'hierarchy' until later today.  I only added the asynchronous behavior to the logger because I mistakenly thought that was the highest level.
> * I also realized that FixFlags.All would be slow by comparison to a partial 'Fix', but I hadn't yet figured out which fields were relevant.  I'm still fuzzy on this as I'm not sure how to tell which fields are required - maybe inferred from the log level?  This seems to be a big issue with the async behavior since it could potentially introduce more harm than good in the current implementation.
> * ThreadSafeBlockingQueue - I'd seen mention of IBulkAppenders but didn't know anymore than what I could infer from the names.  I'm guessing these receive a collection of inputs.  The TSBQueue could certainly be modified.  I was going to create it with generics but I'm guessing log4net doesn't use generics to provide backwards compatibility?
> I'm interested to hear about your other solution since you seem to understand the overall design well.  For now I need to get my application running on top of what I have, but I might be able to lend a hand on this issue going forward.
> Jason
> On 2/17/09, Ron Grabowski wrote:
> > 
> > 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 
> > 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
> >  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.