Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Wed, 6 Oct 2010 07:08:14 -0700 (PDT)
From: boes <gjbh@xs4all.nl>
To: user@geronimo.apache.org
Message-ID: <1286374094034-1642725.post@n3.nabble.com>
In-Reply-To: <F9638542-62B4-457F-9DE6-D8111D071741@gmail.com>
References: <1285948748971-1615458.post@n3.nabble.com>
 <F9638542-62B4-457F-9DE6-D8111D071741@gmail.com>
Subject: Re: Memory leak using Geronimo 2.1.4? Having 116760 instances of
 LifecycleEvent
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I used YourKit to find out that the large amount of LifecycleEvent instances
is normal behaviour of Geronimo Tomcat. It shows that almost every 2 seconds
558 of such LifecycleEvents are generated and when there are something like
200000 of them, the garbage collector removes them from the heap.

The out of memory problem had nothing to do with LifecycleEvents. I created
some heavy load on the server with the use of Apache JMeter and was able to
reproduce the out of memory problem.

As suggested by Kevan I used Eclipse Mat to analyze the heap. I found that a
few instances of org.apache.jasper.runtime.BodyContentImpl where responsible
for holding almost all memory in the heap. This is a well known Tomcat
issue. For some reason the default behaviour of tomcat is to have unlimited
buffer growth for this class. To limit the buffer growth a java option must
be set:
org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true.

After that config change the JMeter test ran without any problem, so it
looks like the LIMIT_BUFFER setting did the trick.

-- 
View this message in context: http://apache-geronimo.328035.n3.nabble.com/Memory-leak-using-Geronimo-2-1-4-Having-116760-instances-of-LifecycleEvent-tp1615458p1642725.html
Sent from the Users mailing list archive at Nabble.com.