Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of tomcat-leak@hotmail.com
 designates 65.54.186.67 as permitted sender)
Message-ID: <BAY16-F173DE50AF5D24443CD3874E17E0@phx.gbl>
In-Reply-To: <BAY16-F36D02B763FE1B0614394F7E17E0@phx.gbl>
From: "Robert Wille" <tomcat-leak@hotmail.com>
To: tomcat-user@jakarta.apache.org
Bcc: 
Subject: RE: Memory leak in tomcat 5.0.28
Date: Wed, 02 Feb 2005 12:25:29 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

I've figured out my problem. I'm posting what I've discovered for the 
benefit of others. The SystemLogHandler uses a map called logs where the key 
is a ThreadWithAttributes and the value is a stack of CaptureLogs. The 
problem is that when a thread dies, the ThreadWithAttributes object lives 
forever because the map is never cleaned out. Threads come and go in the 
thread pool, so stuff keeps accumulating there forever. You can prevent the 
problem by turning off swallowOutput.

logs should be a ThreadLocal, not a map. That way the ThreadWithAttributes 
objects can be collected (as well as the stack of CaptureLogs).

>From: "Robert Wille" <tomcat-leak@hotmail.com>
>Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
>To: tomcat-user@jakarta.apache.org
>Subject: Memory leak in tomcat 5.0.28
>Date: Wed, 02 Feb 2005 09:16:49 -0700
>
>I'm running tomcat 5.0.28 on Linux with JRE 1.4.2_04 and I seem to have a 
>memory leak. I am not using Apache, but am using the Coyote connector. The 
>server has been running under heavy load, being accessed by about 150 
>computers running automated tests. I took heap snapshots about 8 and 20 
>hours into the test using YourKit Java Profiler. When taking the snapshots, 
>I first paused the system for several minutes, attempted to allocate more 
>memory than was available to cause all collectable objects to be collected, 
>and then took the snapshot. Therefore, the snapshots should contain very 
>few collectable objects, and there should be very few open http 
>connections. The following seems very suspicious:
>
>The last snapshot shows 419 Http11Processor objects referencing 41M of 
>memory. That is an increase of 232 Http11Processor objects.
>
>It also shows 81,829 objects in the org.apache.tomcat.util.buf package, 
>which reference 37M of memory. This is an increase of 44,874 objects.
>
>The buffers and Http11Processor objects appear to be referenced by 
>org.apache.tomcat.util.threads.ThreadWithAttributes. I show 425 instances, 
>which is an increase of 225.
>
>The first snapshot was 8 hours into the test, and in reality, I think the 
>system should have reached steady state just a few minutes into the test. 
>But I am obviously accumulating a lot of stuff.
>
>Can somebody help?
>
>Robert Wille
>
>_________________________________________________________________
>Don�t just search. Find. Check out the new MSN Search! 
>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>

_________________________________________________________________
Don�t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org