logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Proposed synchronization changes
Date Mon, 19 May 2008 16:22:31 GMT
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message