Deadlock between FileHandler and ConsoleHandler when using customized formatter

[Shi Jun Zhang]

On 12/9/2013 8:04 PM, Peter Levart wrote:
> 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
>
But shutdown hook will not be executed if VM crashes or exit abnormally.

-- 
Regards,

Shi Jun Zhang