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