Name: gm110360 Date: 10/16/2003


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

ADDITIONAL OPERATING SYSTEMS :
Probably is the case for all operating systems.


A DESCRIPTION OF THE PROBLEM :
The logging API is synchronized. When logging an exception
with Logger.log(Level, String, Throwable)
the Throwable.getMessage() is called within a synchronized
block. This causes a deadlock situation when the
getMessage() is overridden and contains a RMI call to the
same server that is calling the log message.

This is because every RMI call creates a new thread. This
new thread then attempts to aquire a lock on the Logger
(there are Logging calls dispersed throughout the entire
application). As the thread that created the RMI thread
still has a lock on the Logger it is in essence 'waiting for
itself'.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Override Throwable.getMessage() to make an RMI call.
2. Put a logging call in the remote method.
3. Call Logger.log() with the exception.
4. The server and client parts of the RMI call must be the
same application (so they are using the same Logger).

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected a Logging Message.
Result is deadlock. This is especially nasty because of the
nature of where the deadlock is occuring. As most of the
application uses the Logging API the entire application
freezes. In addition, as the Logging API is used for
debugging and tracing, it is difficult to figure out what is
going on.

CUSTOMER WORKAROUND :
Do not override getMessage() in Throwable. Instead have the
String message created and passed to the constructor. This
is not desireable as in this case the getMessage() is
resource intensive and we would like to offload that burden
to the client.
(Incident Review ID: 179594)
======================================================================