This issue did never came up until a few days ago. I had a long discussion with Erik Meade on irc on quite a similar problem. (irc://irc.freenode.org:6667 on channel #apache-log4j)
At 02:17 PM 10/24/2003 -0700, Elias Ross wrote:
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]
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime;
ApacheCon US 2003, 18-21 November http://apachecon.com/--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
