https://issues.apache.org/bugzilla/show_bug.cgi?id=50213
--- Comment #2 from Curt Arnold <[email protected]> 2010-11-06 10:59:27 EDT --- The deadlock that you are experiencing isn't likely due to the lock on category. There are likely two other locks in conflict that result in cascade of blocks. Could you attach a full dump to see if we can pick out the blocks that start the problem. I am assuming that you've used you modified version of log4j and you saw an improved experience. It might possibly isolate the threads where you might still have the initiating deadlock but it doesn't spread to any other thread that logs on the same logger which would be a very beneficial change. Changing the result type of Category.removeAppender(Appender) and removeAppender(String) breaks compatibility with any compiled app that calls either method as they will now could throw a NoSuchMethodException, see http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45208. Also, as you saw with NOPLogger, it requires any extended Logger (discouraged, but not prevented) to be modified. Replacing the lazy construction of AppenderAttachableImpl might have some, but likely small, performance impact. It likely was a big deal in the JDK 1.1 days when object creation was substantially more expensive. The member is package visible (no explicit public, private or protected) so the only way that it could become null again is if something in org.apache.log4j set it null and scanning the rest of the source shows no place that that could occur. Touching synchronization in Category is a minefield. It could be safer to approach this by introducing a new class extended from Logger that is inherently thread-safe and then allowing the user to configure to use the corresponding logger factory when they want the new behavior. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
