On 11/28/2013 8:13 PM, Peter Levart wrote:
On 11/28/2013 08:53 AM, Shi Jun Zhang wrote:
The problem is that we use a logger in CustomerFormatter and this
causes Logger.log call Logger.log itself. As FileHandler.publish and
StreamHandler.publish is synchronized, but the iteration to call
publish method for all handlers in Logger.log is not synchronized,
the deadlock happens.
Hello Shi Jun Zhang,
Why do you use Logger.log in the CustomerFormatter? What are you
achieving by it? Do you want to re-route and re-format messages
destined for one handler to some other Logger and consequently handler?
Hi Peter,
This happens in a real complicated application and I simply the test
case. There is some complicated logic in the CustomerFormatter and we
add some debug log messages in CustomerFormatter.format() method. As
CustomerFormatter.format() method is called in Logger.log, there would
be an infinite recursion if we do nothing, then we have to add some
check to break the recursion. The things we are doing here are 1) using
CustomerFormatter as logger formatter and logging in an application. 2)
logging some debug information in CustomerFormatter.
On 11/28/2013 08:53 AM, Shi Jun Zhang wrote:
This violates the Java doc for java.util.logging.Logger that says
"All methods on Logger are multi-thread safe."
I don't know for sure, but I think that "multi-thread-safe" does not
imply "dead-lock-safe". It would be good if java logging used less
locks and be less deadlock-prone though. So we should see if it is
possible to remove some locks, not to add more locking...
Regards, Peter
I agree that we need less locks in java logging, java logging is getting
more complicated and getting more deadlock recently.
--
Regards,
Shi Jun Zhang
