Curt Arnold wrote:
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.
My hope is that the synchronization improvement I proposed thus far
(taking either the pre-Java-5 or post-Java-5 AppenderAttachableImpl or
even using reflection to instantiate the latter conditionally) is
reasonably safe even for 1.2.x (except that a hard dependency on Java 5
needs to be avoided). At this high level I don't see anything else
inherent in the Logger/Category that is a major bottleneck, though I'm
sure there's room for improvement. [I always though setLevel should
push the effective level down the tree so getEffectiveLevel could be
even faster, for instance.] It would thus seem one could leave the
existing Appender and Layout stuff "as is" and implement a parallel set
of reduced-locking Appenders and Layouts without having to invalidate or
toss out the existing ones. One could thus imagine log4j being
refactored into "core", "compat", and "ng" (next generation) modules.
In the nearer term my proposed changes would at least reduce the
duration of synchronization in any cases where multiple appenders are
being used on one logger and allow one to produce a high-performance,
reduce/no lock Appender as/where desired.
Thoughts?
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
