At 20:18 08.10.2002 +0100, you wrote:
>Hi Ceki,
>
>We don't use a log4j config file, per se. We specify all the properties
>that our
>service needs at startup in an xml file, which is configured by a GUI. The
>properties below are the log4j properties that we specify.
>
>log4j.appender.Default.SyslogHost=localhost
>log4j.appender.Default=org.apache.log4j.FileAppender
>log4j.appender.Default.File=/home/orbtest1/TudorTests/distrib/etc/log/BrowserLog.log
>
>log4j.rootLogger=Debug, Default
>log4j.appender.Default.Append=true
>log4j.appender.Default.layout=org.apache.log4j.SimpleLayout
1) Why is the 'SyslogHost' property being set for a FileAppender?
2) Is the file BrowserLog.log used by someone else? For example, do you
redirect System.err to this file? (This is important.)
3) Are you sure that that's the complete log4j configuration?
>Your other reply makes sense, although all our logging is done to a file.
>In the
>deadlock report from the JVM the deadlock indicates that the first thread is
>waiting for the stream to the file and the second has this stream locked. This
>backs up your theory about the logger wanting to write to a locked object,
>however,
>the first thread should just wait for the lock to be released, which never
>happens.
>We think that this is because the second thread is waiting for a lock to
>an object
>which the first thread already has locked. The thing is that the second thread
>isn't a thread in our service, it's an orb thread that has had it's attempt to
>peform console output error reporting intercepted and re-routed to our
>service log.
Calling a log4j printing method, e.g. Logger.debug() or Logger.info(),
involves at least two locks: first the logger where an appender is attached
and second the appender itself. In your case, each log operation locks the
root logger and the FileAppender named Default.
Are you saying that the console is re-routed to log4j? If that is the case,
then as long as log4j can write to the file everything will be fine. But
when there is a problem with the file, then log4j will attempt to report it
on the console. At that stage, the root logger and the FileAppender named
Default are locked. However, if the console is redirected to use log4j,
then the redirection will re-acquire the lock on the root logger and the
Fileappender. The same thread can re-acquire the locks it already has. Example:
void foo() {
synchronize(some_lock_called_x) {
...
synchronize(some_lock_called_x) {
this point is reachable, no deadlock will occur.
}
}
Unless of course the System.err redirection places a task on a *different*
thread. That will cause a deadlock.
>Thanks for your attention and swift responses.
>
>Paul
--
Ceki
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
