On Sep 21, 2007, at 3:18 PM, James A. N. Stauffer wrote:
We don't redirect System.out or System.err. Both stack traces showed
that both threads were calling logger.debug or logger.info.
Calling stacks would be very helpful to try to analyze the problem.
The most obvious way to get a deadlock where one of the monitors is
RootLogger or RootCategory would be when a log request is made
(possibly indirectly) in the course of processing a log request.
On Sep 21, 2007, at 10:18 AM, James A. N. Stauffer wrote:
After years of using log4j I also encountered this. Is it a freak,
rare occurance or is there a cause that can be addressed?
Finer grain and provably safe concurrency is the primary design
objective for log4j 2.0 and can not be achieved without significant
implementation and API changes (hence why it has to be part of log4j
2.0 and not a 1.x). The internals of log4j 1.x are not thread-safe
but depend on coarse-grained locks to prevent more than more one log
request to be processed at a time. The coarse grained locks
significantly impact performance on multi-core machines and leave the
potential for these types of deadlocks. Individual problems can be
analyzed and fixed or worked around, but eliminating all potential
problems requires a near complete rework.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
