This sounds like a plan. On 6 Nov 2016 8:25 p.m., "Joe" <jocular...@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. > > > > >
