logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piers Uso Walter <Piers.Wal...@ilink.de>
Subject Re: [log4j2] A little bit fluent
Date Fri, 04 May 2012 15:10:47 GMT
Thanks. I'm glad to head that this will not be an issue with log4j 2.

Regarding log4j 1, as far as I know we do not even need to hold the log while calling logger.debug
in order for the deadlock to happen. The toString() method of the object that is to be logged
could (and apparently does in real life scenarios) request the lock, which seems to trigger
this bug.

By the way, we resort to very ugly workarounds to circumvent the bug in log4j 1 (i.e. we make
sure that toString() is always called before the logging method, which prevents the deadlock,
but has the nasty side effect that toString() is always called, even if the logging configuration
would cause no log to be written - thereby defeating log4j's whole concept of trying to be
as lightweight as possible).

With kind regards


Piers Uso Walter <Piers.Walter@ilink.de>
ilink Kommunikationssysteme GmbH

Am 04.05.2012 um 16:26 schrieb Ralph Goers:

> Logj2's locking doesn't resemble Log4j's at all.  I will create a unit test when I have
a few minutes for this use case to insure it doesn't happen.  However, I would also argue
that with Java 5 holding a lock while calling logger.debug should never happen.  Even if Log4j2
itself doesn't cause a deadlock, with this kind of locking going on it could easily happen
within an appender.
> Ralph
> On May 4, 2012, at 5:14 AM, Piers Uso Walter wrote:
>> This is slightly off topic, but please be aware that if you log generic objects (as
opposed to strings), you may run into a race condition that is tracked as bug #24159.
>> When using log4j with JBoss, this potentially causes the whole JBoss server to hang.
>> Our customers were not amused, when they ran into this...
>> I do not believe that this is fixed yet in log4j 1.x
>> With kind regards
>> Piers
>> -- 
>> Piers Uso Walter <Piers.Walter@ilink.de>
>> ilink Kommunikationssysteme GmbH
>> Am 04.05.2012 um 14:08 schrieb Gary Gregory:
>>> What I DO need though is bulk logging where I can pass in an array of messages:
>>> logger.debug(List<?>) (or Collection?)
>>> logger.debug(Object[])
>>> logger.debug(Properties)
>>> For example, I'd like to be able to do:
>>> logger.debug(System.getProperties());
>>> and have it log one entry per property. I am not sure what the format of each
entry is but a sensible default can be provided.
>>> Gary
>>> -- 
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory

View raw message