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