It's not just a single thread. There's my thread and some internal Log4J
dispatcher thread. I should have sent you the JProfiler traces to show
you. Unfortunately I've already rewritten the failover to be handled by
a separate thread instead of the error() routine in the ErrorHandler
derived object.
I'd love to recreate it for ya but I'm under heavy project priorities
and don't have the time right now.
It's not to hard to recreate. I had simplfied down to a simple console
app, MySQL with a table with some simple columns and plumbed up the
JDBCAppender. Also created a RollingFileAppender as the backup. Next you
just start the app without the MySQL running. Or just simply I guess
don't even mess with an actual DB setup at all.
In the class FallbackErrorHandler put a break point on
l.removeAppender(primary);
And try to step into it, or put a breakpoint on the line following it ->
LogLog.debug("FB: Adding appender ["+backup.getName()+"] to logger
"
+ l.getName());
You'll find you'll never hit the breakpoint.
Al Harper
-----Original Message-----
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 05, 2005 3:33 AM
To: Log4J Developers List
Subject: Re: Appender, ErrorHanlder fail over deadlock
On Saturday 05 March 2005 02:40, Harper, Allen (AHARPER) wrote:
> In a nutshell heres whats happening. The entire instance of the logger
> is syncronized. (Actually the syncronized object is the Category
> object from which the Logger is derived.) A caller makes a log call
> Log.xxxx(), in this case the JDBC appender. If the database is down
> the DB call throws which in turn calls the errorHandler, which in turn
> calls back into the Logger (deadlock) to swap out the primary and
> backup appenders.
I am on the same line of thinking that Ceki... How can you say that a
single thread makes a deadlock??
This will not block;
public class Test
{
private int m_counter = 10;
public void doSomething()
{
synchronized( this )
{
while( m_counter-- > 0 )
doSomething();
}
}
static public void main( String[] args )
{
Test t = new Test();
t.doSomething();
}
}
so another thread is involved somewhere in your case.
Hitting Ctrl-Break (Windows) or Ctrl-\ (Linux) will give you a stack
dump with the monitors acquired and waited upon.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
