On Jun 8, 2007, at 3:28 AM, Ortwin Glück wrote:
Hi,I have implemented an asynchronous appender that greatly reduces synchronization. It contains not a single synchronized statement, relies on naturally thread-safe operations and just uses two classes from the java.util.concurrent package. Still it is completely thread-safe. I am using this for logging on J2EE application servers with hundreds of threads. It can be twice as fast as the AsyncAppender depending on the scenario. Of course it comes at a price: it may drop LoggingEvents in peak situations. But that's exactly what I wanted. Better loose some log than block a thread.Is there an interest from Log4J developers to include such an appender in the stock version of Log4J? It's coded against the Log4J-1.2 API and has a JDK-1.5 dependency. JUnit Test cases are available. Just 250 lines of code including API doc. I'd be happy to contribute it.Kind regards Ortwin Glück
Was your performance comparison between the AsyncAppender in log4j 1.2.14 or AsyncAppender from earlier log4j's? If you only looked at earlier AsyncAppenders, it would be very helpful if you could determine the performance of the current AsyncAppender. Since you mentioned that you discard events in peak load, you should set blocking=false on the new AsyncAppender to keep the comparisons fair.
The JDK 1.5 dependency would be a blocker for it going into the log4j 1.2 core. Could be made into a "companion" if it offered a compelling performance advantage, but I'd much rather find a small performance tweak for AsyncAppender than to introduce an alternative.
Can't speculate too much without seeing the code. If you'd like to create a bug and then attach a file to the bug (it is a two step process in Bugzilla), we'd look at it. If you do, please make sure that could code contains the proper notice in the header (http:// www.apache.org/legal/src-headers.html). You should review the Contributor License Agreement (CLA) at http://www.apache.org/ licenses/ which covers things like that stating that the contribution is an original creation and that you have rights to contribute it. Depending on the nature of the work, we may require a CLA on file to incorporate a contribution. At this point, that would be premature, but if you look at the CLA and see something that would prevent your signing it (for example, if you were trying to contribute something that someone else wrote), then that should be addressed early instead of later.
smime.p7s
Description: S/MIME cryptographic signature
