NDC.remove() and throughput in J2EE

[zze-ironman LIGNE E ext DvSI/SIReS/GRE <el...@rd.francetelecom.com>]

Hello

I just noticed a well-known problem in forums, concerning NDC static
table keeping
infos that should have been released if no use of log4j. 
In a J2EE environment, as threads are long-lived in a pool, this
eventually causes 
memory leaks. Workaround seems to be to call NDC.remove() each time a
servlet/ejb ends
its service, or so.

The problem I found here is that NDC.remove() actually does 2 different
things :
1. clears the current thread' context (this is what I wanted) : this is
rather efficient,
parallel, nice (nota : why not use ThreadLocal instead of a synchronized
Map with Thread as key ?
this should evacuates the use of this synchronized map no ?)
2. Searches throughout the entire table to search for references to dead
threads, synchronizing on
the entire table

The second point seems to me to be a performance-killer, as any time
NDC.remove is called, any access
to this class is blocked. If all servlets/EJBs call NDC.remove after
each service as it is said in
the workaround, then logging becomes sequential.

What about creating a low-priority thread specialized for this second
task (as in configureAndWatch
feature), say in a static block of NDC (so if noone calls NDC never, no
thread), and removing this
second task from the NDC.remove() implementation ?

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