> Each async appender (with async=true) would maintain it's own > lazy-writer thread (does this need to be capped? i.e. could > too many threads be created slowing things down due to a high > number of context switches, this would really be dependent on > how many async appenders are configured). > The lazy-writer thread is obviously only created when async > has been set to true. > I would prefer dedicated thread(s) over say the ThreadPool.
Log4net could create its own thread pool for use by async appenders. http://staff.develop.com/woodring/dotnet/#threadpool > Rather than using a CyclicBuffer would it be better to use The cyclic buffer is just an implementation of a leaky bucket. It does not seem to be the right thing to use with the async appenders. > some form of ConcurrentLinkedQueue [1] allowing appends to > take place whilst the front of the queue is being serviced, > this would allow continual writing whilst appending allowing > the logging application to continue work. Does sound good. With async appenders will it become more common for appenders to log groups of messages rather than individual messages? i.e. will Append(LoggingEvent[]) be more useful than the current Append(LoggingEvent)? How will this affect the synchronous API, will we need both or will one do? Cheers, Nicko
