Deadlock between FileHandler and ConsoleHandler when using customized formatter

Daniel Fuchs daniel.fuchs at
Mon Dec 9 10:12:27 UTC 2013

On 12/9/13 9:58 AM, Peter Levart wrote:
> On 12/09/2013 09:51 AM, Shi Jun Zhang wrote:
>> On 12/9/2013 4:28 PM, 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
>> Hi Peter,
>> We have thought about moving formatter out of the synchronized section
>> of Handler.publish(), it can avoid the deadlock. However, we can
>> reproduce the similar deadlock by extending the Writer in Handler and
>> using logger in the customized Writer.
> That's right. And the remedy for that situation would also be what Jason
> Mehrens suggested - asynchronous publishing.


I agree with Peter & Jason - asynchronous publishing seems like a good
solution. I believe the LogManager will close all handlers on exiting,
so you might want to make sure that your asynchronous handler flushes
the queue before quitting - which could still be tricky if flushing
the queue produces new log messages for the queue - and also because
you will want Handler.close() to wait until the queue is empty.

Anyway - the best advice still is IMHO - don't call Logger.log while
publishing a log message. This should save you from a lot of issues,
like the one you encountered - but also possible stack overflows etc...

best regards,

-- daniel

> Regards, Peter

More information about the core-libs-dev mailing list