On Fri, 2003-10-24 at 14:17, Elias Ross wrote:
[cut]
> So, I am wondering why can't the rendered render without holding the
> lock on 'org.apache.log4j.spi.RootCategory'?
I'm replying to myself, I know...
Another work-around for this sort of deadlock would be for me write,
instead of log.debug(s), this sort of statement:
if (log.isDebugEnabled())
log.debug(s.toString());
That led me to wonder why any locks would have to be held at all while
'rendering' the object "s"...
Looking at the code in 1.2.8, there are two locks being held. One is in
Category.callAppenders. Right away, I realized there is another
(better) way to write this routine without holding any locks...
[before]
for(Category c = this; c != null; c=c.parent) {
// Protected against simultaneous call to addAppender,
removeAppender,...
synchronized(c) {
if(c.aai != null) {
writes += c.aai.appendLoopOnAppenders(event);
}
if(!c.additive) {
break;
}
}
}
[after]
for(Category c = this; c != null; c=c.parent) {
// Protected against simultaneous call to addAppender,
removeAppender,...
AppenderAttachableImpl aai = c.aai;
if (aai != null) {
writes += aai.appendLoopOnAppenders(event);
}
if(!c.additive) {
break;
}
}
The second lock comes from AppenderSkeleton:
public
synchronized
void doAppend(LoggingEvent event) {
if(closed) {
LogLog.error("Attempted to append to closed appender named
["+name+"].");
return;
}
Here is the stack trace:
This cannot be removed without affecting established
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
