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]