Hello,
Is the developer knowingly calling NDC.push? If so, she should also
call NDC.remove() as documented in the NDC javadocs. However, you seem
to be saying that "Tomcat" or some other entity is calling NDC.push
without the developer's intervention, which if were true, I'd be quite
surprised about.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
[email protected] wrote:
When running Apache Tomcat 5.0.28 configured with Apache Commons Logging
and Log4J there appears to be a serious resource leak which results from
the per thread Nested Diagnostic Context created by Log4J.
Consider the following usage scenario;
A Tomcat-5.0.28 server configured with 50 threads min, and 100 threads
max. And a VM heap of 400mb. The commons logging has been configured to
use Log4j-1.2.15
A Servlet which handles a reasonable volume of data (like a large sql
query or a big xml file) is written and emplaced at “/test”
A testing application can then be written which will deliberately create
100 simultaneous connections to Tomcat, each querying the “/test” Servlet.
Upon hitting the thread limit of 50, Tomcat will create more threads to
reach its max of 100, each of these threads will in turn make a call to
org.apache.log4j.NDC.push(..) to create a new logging context per
thread. The testing application will then pause for a short while to
allow Tomcat to reduce the Thread count back to 50. When Tomcat reaches
50 threads, references to the previously created 50 temporary threads
are still held in the NDC hashtable. These threads are never freed
unless a call to org.apache.log4j.remove() is made either explicitly per
thread, or once to allow the lazy evaluation and cleanup.
As far as I can tell, in the way that Log4J is used within Tomcat and
Apache Commons Logging described here, this never happens, and the
Servlet developer certainly isn’t responsible for calling
org.apache.log4j.remove() as they don’t necessarily know they are even
using or deploying on Log4J.
The above scenario can be made to cause Tomcat to run out of memory in
as little as 15 minutes, with a 400mb heap.
As far as I know, this will affect all current and pervious versions of
Tomcat using Log4J and Apache Commons Logging, and any other application
servers with similar logging, i.e. JBoss.
The above results can be verified using a heap profiler in Java 1.6, and
many references to similar problems can be found online.
>
Emerson
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
