Jess Holle wrote:
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?
If it is sufficiently compelling it appears it would be possible to
rework AppenderSkeleton without breaking most extensions thereof but
allowing Layout.format() to be hoisted out of the synchronization block
in cases where the Layout is an instance of some special interface. [I
was hacking away at this approach when I ran into the issue with
PatternLayout.] The point here would be to reduce the bottleneck
imposed by today's Appenders and Layouts while only reworking some
Layout classes.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
