logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: NDC implementation log4j-1.2.8
Date Wed, 27 Oct 2004 19:07:27 GMT

A couple of things: 

- 1.2.8 is not likely to change.  There won't be a 1.2.9.  Effort is
focused on 1.3, so any contributions should be made against the 1.3
codebase which is in CVS HEAD.
- 1.2 is designed to work on JDK 1.1 as well, and ThreadLocal is not in
JDK 1.1, so it can't be used on log4j 1.2.

Yoav Shapira http://www.yoavshapira.com

>-----Original Message-----
>From: E. Epstein (ML) [mailto:mailing-list@prajnait.com]
>Sent: Wednesday, October 27, 2004 3:01 PM
>To: log4j-dev@logging.apache.org
>Subject: NDC implementation log4j-1.2.8
>Hi Ceki, et. al.:
>I think this belongs here, in the developers list.  If, however, you
>decide it does not and should instead be posted in the user list,
>accept my apologies in advance and just let me know and I'll repost
>We have a system using NDC that kicks off threads to perform various
>functions asynchronously.  When all goes well the threads exit and
>before doing so call the NDC.remove() method as per the docs.  This is
>hybrid Java / JavaScript system so the problem comes in the JS code
>where Rhino has control.  We cannot guarantee that if the thread dies
>violently that we'll get a chance at cleanup!  We're concerned about
>leaking memory via this dead threads.... OK, that's the motivation, now
>for the part of this message that is dev related.
>Digging into the NDC.java class I noticed that the issue seems to
>revolve around the use of a Hashtable to store associated the nested
>diagnostic contexts with their respective threads.  I'm wondering if a
>ThreadLocal wouldn't work just as well and skirt the issue of retaining
>references to threads via the Hashtable.  In addition I think it would
>offer a nice performance boost.  Looking at the comments in
>"lazyRemove()"  I found this comment:
>      // The synchronization on ht is necessary to prevent JDK 1.2.x
>      // throwing ConcurrentModificationExceptions at us. This sucks
>      // One solution is to write our own hashtable implementation.
>The ThreadLocal class and its standard pattern remove this issue as
>well.  They'd also remove the need for the package-private pushCounter
>I'd like to code this up using ThreadLocal but wanted to not if
>someone's already about to do so -- or has done so and its in CVS
>I didn't check, I just took the latest release: 1.2.8).  Also, I
>that both static variables: Hashtable ht and int pushCounter are
>declared package private rather than class private, and although I
>searched the source tree and couldn't find any reference to NDC.ht or
>NDC.pushCounter, I didn't want to see something break just because I
>didn't find a reference when in fact there is one.
>Thanks for staying with me for this lengthy post.  So.... having not
>contributed to log4j before, what step next?  Should I just submit a
>ThreadLocal version of the file?
>= Ezra E.
>P.S., Since writing this I've gone ahead and changed NDC.java.  It
>compiles and passes basic tests.  It is gzipped and attached here.

This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.

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

View raw message