logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Proposed synchronization changes
Date Tue, 20 May 2008 14:43:32 GMT

On May 20, 2008, at 4:19 AM, Jess Holle wrote:

> Curt Arnold wrote:
>>
>> On May 19, 2008, at 11:22 AM, Jess Holle wrote:
>>> 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
>> Did you check out the "concurrent" contribution in the sandbox, http://svn.apache.org/repos/asf/logging/sandbox/log4j/concurrent?

>>   See also http://marc.info/?l=log4j-dev&m=110623974420412&w=2.
> I think I knew about this a long time ago, but I'd forgotten about it.
>
> It looks like a good start on producing a parallel Appender  
> hierarchy.  It would seem that one could use the concurrent  
> PatternLayout from here with existing Appenders if one adds a tag  
> interface to the concurrent PatternLayout and some extra code to  
> AppenderSkeleton -- if this proved compelling.  Also, one nit: the  
> concurrent PatternLayout.format() should use StringBuilder, not  
> StringBuffer.
>
> That said, none of this would seem to buy you anything if you don't  
> remove the synchronization bottleneck in Category.callAppenders(),  
> e.g. as per my patch.  This patch would enable a high-concurrency  
> branch.  Without this patch, everything is still bottlenecked in  
> Category as best I can tell.
>> As we are very far along in the log4j 1.2.x lifetime, removing  
>> synchronization points in the main-line of the code is very high  
>> risk activity.  The concurrent proposal basically created a  
>> parallel package of classes that had different synchronization  
>> guarantees and so would not require proving that a particular  
>> modification would be safe for all potential uses.
> I'm fine wit the concurrent proposal except that Category still  
> needs to be changed.  I also wonder whether an ability to opt-in to  
> improved concurrency by using a concurrent Layout and an existing  
> "non-concurrent" Appender would be helpful.
>
> One question: I notice ConcurrentAppender uses 'guard' to explicitly  
> prevent re-entrancy.  I don't notice anything to this effect in the  
> existing "main-line" Appenders.  Am I missing something?  Or is  
> there an intent in existing Appenders to allow re-entrancy?  Or do  
> they just not guard against this and run into issues upon re-entrancy?
>

I never went deep into the concurrent contribution.  The project  
accepted it in the sandbox from Elias Ross and granted him commit  
rights for continued development, but it did not develop a community  
and Elias drifted away.

Having anything in an appender or layout that in turn calls log4j is  
unsafe and may likely cause infinite recursion.  log4j 1.2.x won't  
stop you from that.  Looks like the concurrent contribution attempted  
to block it.

I think incrementally improving log4j 1.2, particularly in the area of  
concurrency is a morass.  Since individual components of log4j 1.2  
were not designed to be thread-safe and the contract with extensions  
allowed them to not be thread-safe, removing any existing  
synchronization block is extremely difficult to be proved generally  
safe.  Removing the category synchronization lock may work for you or  
allow the unit tests to run (which are far from a thorough test of  
log4j), but it screams like the type of thing you don't do in the 16th  
dot release.

The log4j 2.0 approach was to design the fundamental building blocks  
designed for concurrency and JDK 1.5 and then when that foundation was  
sufficiently established, start migrating appenders and writing log4j  
1.2 emulation on top of it.  Right now it is a few experiments in the  
sandbox and not as accessible as I would like.  If I were going to  
spend my time on concurrency related issues, the best use of my time  
would be to make it more accessible and complete.  If you are  
interested in contributing to that, I'd be willing to change my  
priorities and update that.

If you really want to work on an incremental approach, I'd be willing  
to create and apply your patches to a branch of log4j 1.2 in the  
sandbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message