Deadlock between FileHandler and ConsoleHandler when using customized formatter

[Peter Levart]

On 12/09/2013 10:50 AM, Shi Jun Zhang wrote:
> 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.
>

You could install a shutdown-hook that would make sure the remaining 
queue is flushed before completing the VM exit...

Regards, Peter