Hi again,
Thanks for your help with this, we do redirect any calls to System.err to the log. This
has been minimised in our code and all calls of this kind are Debug.error calls. The
problem occurs in this case because we are working with a number of third party systems
which produce output to wherever they like.
If it is a possibility that System.err could be redirected through log4j then should
log4j produce error messages to System.err? This would cause this deadlock to occur in
most multithreaded systems that chose to redirect all their output to a log.
For our purposes we are thinking of making the use of System.err error messages
configurable in log4j (or removing them completely). Adding a simple on/off flag for
error messages should be sufficient. If something goes wrong with the logging then it
will just stop if the System.err flag is turned off, otherwise it will just do what it
does now.
I've only looked at the pieces of code that our deadlock issue struck and I've seen
that
the System.err call occurs in a catch block, presumably it will be acceptable to add a
property check after an error has occured as performance of the functioning system will
not be affected. Let me know if this is not the case.
These are just my preliminary thoughts for a work-around for our problem. Let me know
any
thoughts that people may have on this method.
Thanks again for your attention and time.
Paul
> 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]>
--
Paul Graham
Software Engineer
Prismtech Ltd, UK
http://www.prismtechnologies.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
