Deadlock between FileHandler and ConsoleHandler when using customized formatter

[Shi Jun Zhang]

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