[
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.
