https://issues.apache.org/bugzilla/show_bug.cgi?id=41214
--- Comment #36 from Bartek <[email protected]> 2011-04-11 05:05:56 EDT --- Agree that the deadlock is not caused by log4j itself. It's caused by the design of the given app, i.e.: - the fact that logging an exception through category A causes the exception to log an event to log4j through category B; ... and both categories use the same appender - using renderers that log to log4j inside their code in a scenrio similar to the one described above While it's not log4j that is the direct cause of these issues, if log4j classes were synchronized differently, these problems would not be observed. If org.apache.log4j.Category.callAppenders() would use a reentrant read write lock, thread that called category A, then called appender which caused category B to be called would not be blocked on org.apache.log4j.Category.callAppenders(). What is more, as org.apache.log4j.Category.callAppenders() is no longer a problem, this thread would be able to reenter the lock on org.apache.log4j.AppenderSkeleton.doAppend(). Deadlock would not be observed. I also mentioned changing locking mechanism used in org.apache.log4j.Category here https://issues.apache.org/bugzilla/show_bug.cgi?id=50213#c6 I'll create a seperate Bugzilla ticket for this propsed refactoring. Oh, of course introducing async appenders could be used as a workaround for these serious issues - for deadlocks. However, org.apache.log4j.Category.callAppenders() is anyway suboptimal. Bartek -- 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]
