Deadlock between FileHandler and ConsoleHandler when using customized formatter

[Shi Jun Zhang]

On 12/9/2013 4:40 PM, Peter Levart wrote:
> On 12/09/2013 09:28 AM, Peter Levart wrote:
>> On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
>>> Peter,
>>>
>>> I think you are misunderstanding this problem. This deadlock is not 
>>> related to the formatter synchronization, we can make 
>>> CustomerFormatter.format not synchronized and not call super.format, 
>>> the deadlock still happens.
>>
>> I'm not saying that your formatters are explicitly synchronized - all 
>> formatters are currently effectively synchronized by LogHandlers. The 
>> Formatter is invoked from within LogHandler's publish() method which 
>> is synchronized (on LogHandler.this). If formatters were invoked out 
>> of this synchronized section, there would be no danger of deadlocks 
>> when using Logger.log from within custom formatters. But then other 
>> issues would arise as a consequence of non-multithreaded formatters 
>> being invoked concurrently...
>>
>> Regards, Peter
>>
>
> I think the best solution to your problem (or a work-around if you say 
> so) was suggested by Jason Mehrens few messages ago - decoupling of 
> user code from publishing of log records - by creating an 
> AsyncLogHandler that is just feeding a FIFO queue with log records 
> which are processed by a background thread by pop-ing them out of 
> queue and sticking them in the actual LogHandler.publish(). If the 
> queue is unbouded or large enough so that it never fills up, there's 
> no danger of dead-locks even if you invoke Logger.log from custom 
> formatters in such background publishing thread.
>
> Regards, Peter
>
Hi Peter,

Would the following situation happen if we use AsyncLogHandler? Some 
error happens and it causes the jvm crashes or System.exit() is called, 
however the related log record which contains important message is still 
in the queue and not printed. If so, I think it's unacceptable.

-- 
Regards,

Shi Jun Zhang