I just came across a deadlock condition in my code brought out by
Log4J. Here is a simplified view of the objects in play:
class State {
Logger log1;
synchronized void setState() {
// Something takes a long time here
log.debug("hello world");
}
synchronized Object getState() {
}
public String toString() {
return "state=" + getState();
}
}
So, imagine that I call in thread (1)
Logger log2;
State s = new State();
log.debug(s);
And then, in another thread (2), I called setState(). It is in the
middle of setState when this debug statement is fired.
In thread (1), the logger holds a lock on
'org.apache.log4j.spi.RootCategory'. The renderer attempts construct
the message by calling s.toString(), and toString calls getState().
Thread (1) has to wait for setState in thread (2) to exit. But setState
can't exit until it has finished logging.
So, I am wondering why can't the rendered render without holding the
lock on 'org.apache.log4j.spi.RootCategory'?
(An obvious fix is to not lock the getState routine.)
Maybe the moral of the story is don't have your debug statements hold
locks on your objects.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
