Okay, let me finish, I'm sorry I hit send early by mistake. :-)
On Fri, 2003-10-24 at 15:26, Elias Ross wrote:
>
> Here is the stack trace:
org.apache.log4j.WriterAppender.append(WriterAppender.java:150)
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221)
- locked <d6655dd0> (a
org.jboss.logging.appender.DailyRollingFileAppender)
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
org.apache.log4j.Category.callAppenders(Category.java:187)
- locked <d52e5db0> (a org.apache.log4j.spi.RootCategory)
I suggest what needs to happen is that the rendering stage has to take
place without holding any locks. But that would mean that
AppenderSkeleton would have to be re-written (but only slightly):
1. Holding locks, all major pre-conditions are checked. (Is the event
filterable? Is the threshold set too low?)
2. The message is rendered.
3. Holding any final locks necessary to actually write/output the
message, the rendered message is then sent to disk/the network/wherever.
I've run into this problem two times: One time while using JBoss,
another time using a third-party library that uses log4j. Since more
and more libraries and platforms use log4j (or commons-logging), this
sort of "rendering-interference"--especially on multiple-CPU
machines--is very worrisome.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
