But here's what I do know. The custom appender thread is stuck here:
Thread Name : Servlet.Engine.Transports : 1
State : Deadlock/Waiting on condition
Owns Monitor Lock on [EMAIL PROTECTED] /1CB39290
Waiting for Monitor Lock on [EMAIL PROTECTED]/1C7ED470
Java Stack
at com.hcsc.eas.framework.services.logging.ExceptionAppender.append(ExceptionAppender.java:212)
at org.apache.log4j.AppenderSkeleton.doAppend (AppenderSkeleton.java(Compiled Code))
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java(Compiled Code))
at org.apache.log4j.Category.callAppenders(Category.java(Compiled Code))
at org.apache.log4j.Category.forcedLog(Category.java:372)
at org.apache.log4j.Category.log(Category.java:834)
The monitor it's waiting for is held by the thread we don't have a stacktrace for, but what we do know is this:
Thread Name : ORB.thread.pool : 2
State : Deadlock/Waiting on condition
Owns Monitor Lock on [EMAIL PROTECTED]/1C7ED470
Waiting for Monitor Lock on [EMAIL PROTECTED] /1CB39290
The first thread apparently also owns a lock on a particular logger which all of the other threads are waiting on - the threads all look like the following.
Thread Name : ORB.thread.pool : 7
State : Waiting on condition
Waiting for Monitor Lock on [EMAIL PROTECTED]/1CB50470
Anyway, I'm sure this isn't enough for you to understand the issue - I haven't really untangled it myself and unfortuantely don't have full stacktrace info. But your answer about the pros/cons of log4j 1.3 was helpful. I'll try out the current alpha snapshot with our application and see if it a) works at all and b) helps with our issue.
Thanks again,
Stu
On 6/28/06,
Curt Arnold <[EMAIL PROTECTED]> wrote:
On Jun 27, 2006, at 4:39 PM, Stuart Robertson wrote:
> We're considering dipping our toes into log4j 1.3 waters for a not-
> far-off production application, and would like to get a read on the
> developers' opinion on what areas are stable for production. I
> understand there are no guarantees, we won't hold you to it, etc.
> etc., but still, you probably know which areas are in flux and
> which are already probably how they'll look whenever 1.3 goes live.
>
> We'd actually be using it initially as a backward compatible
> replacement for 1.2 in an application where we're experiencing the
> dreaded deadlock issues, which it sounds like 1.3 may help resolve.
>
> Anyway, thanks for any input.
>
> Stu
Depends on what issue that you are running into.
If you are running into AsyncAppender related deadlocks, the log4j
1.2 branch should have the recent AsyncAppender rewrite in it. I'm
hesitant to support a log4j 1.2.x release with the new AsyncAppender
since there has been very little feedback on it. The log4j 1.2
AsyncAppender was seriously broken, but had been for a long time and
people either weren't using it, weren't running into the problems or
had worked around them. Though there has been no plans for
additional 1.2.x. releases, there is nothing preventing that decision
being revisited.
If you are talking about deadlocks due the message parameter's
toString() method making log4j calls itself, then I'm not sure that
1.3 buys you anything. I haven't seen a way to solve the problem
that doesn't introduce a potential compatibility problem. Though it
wasn't documented, log4j has never (as far as I know) supported that
scenario and so potentially breaking deployed applications to allow
an improvement for new applications is not something that I could
support in a 1.x release.
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 have outline some of my thoughts on log4j 2.0 development in the
past and would love to spend some time brainstorming and getting an
outline and some sample code together. However, I've been resource
constrained due to revenue generating projects. However, I think it
is close to time to opening up a log4j 2.0 branch and getting some
development started.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
