logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Psenner <dpsen...@gmail.com>
Subject RE: Apache log4net Needs Help
Date Mon, 07 Nov 2016 09:00:49 GMT
This sounds like a plan.

On 6 Nov 2016 8:25 p.m., "Joe" <JocularJoe@hotmail.com> wrote:

> > A long time ago I had started a reimplementation of the
> RollingFileAppender because we've seen that we cannot fix it without
> breaking compatibility or redefining its features. Most of the
>
> > issues related to the RollingFileAppender should be marked as related
> issues to the rewrite issue. I dont have the issue id at hand, though. If
> you wanted to pick up that initial work and
>
> > continue it would be awesome! Most probably I am going to jump in
> helping you because the RollingFileAppender is one of the most used
> features and therefore one of the crucial points
>
> > where performance and sanity can make a difference of users moving away
> from log4net or attracting more users.
>
>
>
> I’d be willing to get involved in that.  A suggestion for what I could do
> over the next months:
>
>
>
> 1.  Complete AsyncAppenderSkeleton and AsyncForwardingAppender
>
>
>
> 2. Possibly implement the ability to log to an ILog from an appender
> derived from AsyncAppenderSkeleton if the re-entrancy issues can be solved
> (which I think they can).
>
>
>
> 3. Implement performance counters in AsyncAppenderSkeleton (and maybe
> AppenderSkeleton).  I’ve recently done something similar for a custom
> asynchronous appender, and it should be fairly straightforward to
> implement.  The idea is to make it easy to monitor performance of an
> appender: number of logging events processed, rate at which they’re
> processed, average processing time, queue length when in asynchronous mode,
> …  I’ll create an issue for this in due course with a more detailed
> description.
>
>
>
> 4. Reimplement RollingFileAppender, perhaps as AsyncRollingFileAppender
> derived from AsyncAppenderSkeleton.  It might be useful to be able to use
> it in asynchronous mode, for example to reduce the performance impact of
> contention for the mutex when logging to a shared file.
>
>
>
>
>

Mime
View raw message