On May 19, 2008, at 10:22 AM, Jess Holle wrote:
Jess Holle wrote:
Thanks.
I'm also starting to ponder whether there's a mostly compatible way
to reduce locking in AppenderSkeleton and WriterAppender.
For instance, we could add a special Layout interface that would
allow the String to be pre-computed prior to holding the lock (but
after filters and thresholds).
That's just an idea, but I'm looking for something that does any
message to String conversion and formatting without holding a lock
on the Appender, which would be a source of potential deadlock and
unnecessarily limit the (multi-threaded) throughput of log4j.
Argh! Popular layouts, e.g. PatternLayout, are far from thread
safe. The only thing that saves them today is that they are used in
a single-threaded manner due to the locking in AppenderSkeleton.
Exactly. Almost nothing inside of log4j 1.2.x is inherently thread-
safe and depends on a big, coarse-grained synchronization lock to
insure safety. Almost any incremental improvement has the potential
for breaking compatibility.
Significantly improving the concurrency requires rewriting log4j from
the ground up to be designed for concurrency which is the key mandate
for log4j 2.0 development. Unfortunately, there has been interest but
little participation in the earlier attempts to start to ramp up log4j
2.0 development.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
