I am proposing creating a "shadow" package called org.apache.log4j.concurrent that contains many of the same classes, such as AppenderSkeleton, FileAppender, etc. but allows multiple threads to append at the same time. Most of the inspiration for such a project comes from work done by the java.util.concurrent team, who created concurrent implementations for Map, List, etc., that created minimally locked data-structures.
"Why is such a package needed?" In today's world of hyper-threaded, multi-processor application servers, inevitably there is a need (like any application server library) for a scalable logging solution. "Okay, but it's not like you're logging 100 times a second..." Not necessarily. When diagnosing problems in a running server, one often has to turn on and turn off logging, hopefully without disrupting processing that is occurring on a live system. It would also be a good basis for appenders that could greatly benefit from concurrency, such as SNMP, JDBC, JMS appenders. There wouldn't be any need to lock these as each thread. As each log event is relatively expensive, concurrency would _greatly_ improve these classes, as one thread would not need to hold a lock for 10-30 milliseconds, for example. Often times, a large amount of logging occurs during outage situations. When a database hiccups, or a Servlet class fails (due to bugs), the server tries to log 1000 times a second, causing unrelated threads to block as well. Could log4j bring your server to its knees? "Why not just use the Async appender?" This would improve matters, but it does not allow for synchronous logging of events or take advantage of multi-processors. A possible fix for the latter problem would be creating a thread pool, which would have to be tuned for the installation. "Why not fix the existing appender classes?" Unfortunately, there would be a lot of compatibility problems. Anybody who extended an existing appender class in their own code expects locking to behave in a particular way. (This is the "Inheritance breaks encapsulation" anti-pattern.) "Bloat!" Probably wouldn't require more than a 1000 lines of code for the core part. Obviously, it's more of a chore to get 1000 lines of such code correct, but not impossible. "Nobody would use it. Nobody cares. Why not create it yourself?" I'm somebody, aren't I? I care. I think the log4j project and its users would benefit with an integrated solution, rather than one that comes from an unknown source such as myself. Plus, log4j could itself leverage such a library. In addition, it'd be another simple reason log4j beats java.util.logging. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
