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: log4j features and general readyness for use
Date Wed, 28 Jun 2006 17:34:21 GMT

On Jun 28, 2006, at 11:01 AM, Elias Ross wrote:

> On Wed, 2006-06-28 at 00:04 -0500, Curt Arnold wrote:
>
>> My personal feeling is that 1.3 is in a no-win situation.  Backwards
>> compatibility was not rigidly enforced during development.  While
>> there has been some success reworking the code to be compatible with
>> 1.2.x, I do not think that it will ever be close enough to 100%
>> compatible to be a universally recommended replacement for deployed
>> applications that are working fine with 1.2.x.  However, there are
>> many issues (primarily involving concurrency) that will require
>> breaking binary compatibility with 1.2.x to solve, but log4j 1.3.
>> does not solve them.
>
> I did offer the Log4J team a better designed logging appender package,
> which would be nice to have bundled 1.3, which does solve deadlock
> issues.  Then users who have issues can use appenders from this  
> package
> instead, which are compatible from a configuration point of view.
>
> So, instead of this:
>
> log4j.rootCategory=debug, stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>
> you write:
>
> log4j.rootCategory=debug, stdout
> log4j.appender.stdout=org.apache.log4j.concurrent.ConsoleAppender
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>
> I don't know what the position is for their inclusion.  I'd like to  
> know
> either way where the community stands, a simple Yes or No would be
> appreciated.
>

Your submission does address a specific legitimate problem of logging  
calls during toString() on the message parameter, however that wasn't  
what I was alluding to when I mentioned concurrency issues that  
required breaking changes and could only be addressed in log4j 2.0.

I was primary concerned with log4j 1.2 common approach of having  
internal operations that are not safe for concurrency and wrapping  
them all within a coarse-grained lock.  The toString() issue is a  
symptom, but not the only, symptom of that approach.  The major  
downsides of that approach are that log4j does not scale well on  
multi-processor systems and it is maddeningly complex to do any  
analysis of concurrency issues since very few significant operations  
can be determined to be safe by code review.

However, if the original poster is running into deadlocks due to the  
toString() issue, then using log4j 1.3 and the concurrent appender  
contribution in the sandbox may be an reasonable solution until log4j  
2.0 is available.

For those just coming in, see:

http://issues.apache.org/bugzilla/show_bug.cgi?id=24159
http://issues.apache.org/bugzilla/show_bug.cgi?id=33855

Elias, I would appreciate your reviewing bug 33855 and see if it  
should be marked as a dup of 24159.  You did submit some patches  
against 24159, but I believe the patches in 33855 obsoleted them.

Elias's contribution was been added to the log4j sandbox for review  
and feedback back in February.  Source can be checked out using:

svn co http://svn.apache.org/repos/asf/logging/sandbox/log4j/ 
concurrent log4j-concurrent

Can be built with either Maven or Ant but each require log4j 1.3 to  
be provided.  Ant build:

ant -Dlog4j.jar=/foo/log4j-1.3alpha-8.jar

Maven build requires manually adding a log4j-1.3alpha8 entry to the  
local repository.  Maven doesn't
like the hyphen in "1.3alpha-8".

You would need to add the log4j-concurrent.jar from the sandbox  
project to the classpath in addition to the log4j 1.3 jars.

The contribution was placed in the sandbox to allow the community to  
provide feedback on the contribution, but I'm not aware of any.  If  
there are people who want to step up and say that it worked well for  
them,  that would help.  It might help to have a little more  
discussion, but if you want a simple Yes or No, then the appropriate  
way to get that started would be to call for a vote.  Ideally, you'd  
start with a message that described your proposal in adequate detail  
with a subject starting with [DISCUSS], something like:

[DISCUSS] Migrate log4j-concurrent from sandbox to trunk

When the issue seems to be adequately understood, then call for a  
vote with:

[VOTE] Migrate log4j-concurrent from sandbox to trunk

At that time the rules at  http://www.apache.org/foundation/ 
voting.html and http://logging.apache.org/site/bylaws.html come in to  
play.


---------------------------------------------------------------------
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