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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
