Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
All
Description
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
>