Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Memory Usage Problem with Tomcat
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: <3A198600-C6C2-4312-9525-1DBDB7B33561@earthlink.net>
Date: Wed, 14 Mar 2012 13:44:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4E8FD32-7F43-487B-AF93-17CCF767CE64@objectstyle.org>
References: <8CB6B941-D04C-4F90-9416-6E410139C9D1@earthlink.net>
 <CAM1yOjb71uAmapfysiyKr9mQX3MXWanBsJYXOaKzoW8ZK8nQ_Q@mail.gmail.com>
 <B705B5AB-4F54-49E2-BC88-FA5A4099BFB6@earthlink.net>
 <CAM1yOjbxBnQQSWk4-5jszbENs27FARrbqYs=tr7GNHTQ6Jqg0Q@mail.gmail.com>
 <B577D6D0-BFD3-4FB3-A7D6-15FBA09EFC04@objectstyle.org>
 <F4052018-CF8F-4258-A20E-7A74581711DA@earthlink.net>
 <8B077C09-C2A7-41B1-B127-4E25D0506A97@objectstyle.org>
 <3A198600-C6C2-4312-9525-1DBDB7B33561@earthlink.net>
To: user@cayenne.apache.org

I didn't know how you start/stop Cayenne so I was giving a general =
answer. If you are using WebApplicationContextFilter, it should stop =
Cayenne event threads. Maybe you can run your web app in debugger =
locally, put a breakpoint in WebApplicationContextFilter.destroy() and =
see if it is invoked at all, and when it is called - that the threads =
stop.

Andrus


On Mar 14, 2012, at 12:43 PM, Joe Baldwin wrote:

> Andrus,
>=20
>> You will need something similar.=20
>=20
>=20
> I was following you until you said this.   The link you sent is code =
for the cayenne filter that is intended to be placed in the web.xml file =
for tomcat.  I have already done this.  So is your comment meant to =
imply that I need to *add* the filter, or *write* one myself.
>=20
> Whats more, if I have implemented your filter, then why would I need =
to create another one.
>=20
> Also, are these objects that hold on to my data objects? If so, then =
this is a rather important issue.
>=20
> Thanks
> Joe
>=20
>=20
>=20
> On Mar 14, 2012, at 9:59 AM, Andrus Adamchik wrote:
>=20
>> Ok. Now you are on to something. The remaining Cayenne event threads =
is an indicator that the old version of the app was not undeployed.
>>=20
>> You need to ensure that you shut down your Cayenne Configuration (in =
3.0) or ServerRuntime (in 3.1) when your web application stops. Here is =
an example of how Cayenne does it in =
WebApplicationContextFilter.destroy() :
>>=20
>> =
http://svn.apache.org/viewvc/cayenne/main/branches/STABLE-3.0/framework/ca=
yenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/conf/WebApplicat=
ionContextFilter.java?view=3Dmarkup
>>=20
>> You will need something similar.=20
>>=20
>> Andrus
>>=20
>>=20
>> On Mar 14, 2012, at 9:51 AM, Joe Baldwin wrote:
>>=20
>>> Andrus,
>>>=20
>>> After watching the video you suggested, I tried one of the "tricks". =
 I started up tomcat, with the cayenne enabled app. Then took a snapshot =
with VisualVM. There appear to be 5 instances of
>>> 	org.apache.cayenne.event.EventManager$DispatchThread.run()
>>>=20
>>> This may or may not be normal, however when I redeployed the =
application (via ant-tomcat command) there were then 10 instances.  Each =
time I redeployed the app, another 5 instances were displayed with =
VisualVM snapshot.
>>>=20
>>> I then tried another test, in which I restarted Tomcat (to get 5 =
instances of the EventManager) used Tomcat manager to undeploy the app =
(which ostensibly wipes the app from the tomcat dir structure), however, =
the 5 instances of the EventManager were still showing up in VisualVM =
snapshot.
>>>=20
>>> Mark Thomas (the video lecturer), said that this all *might* =
indicate a leak.  However, since I am unfamiliar with the intended =
behavior, I cannot be sure.  On the other hand, having these 5 instance =
multiply each time the app is redeployed does not seem like it is =
standard behavior.
>>>=20
>>> Thomas described an on behavior in which just adding a JDBC jar file =
to your WEB-INF/lib dir could cause a leak.  The reasoning behind how =
the class loaders work was a bit convoluted, but I am wondering if these =
behaviors are related.
>>>=20
>>> So my question is what behavior would you expect, and what should my =
next test be?
>>>=20
>>> Joe
>>>=20
>>>=20
>>> On Mar 13, 2012, at 4:47 PM, Andrus Adamchik wrote:
>>>=20
>>>>=20
>>>> On Mar 13, 2012, at 4:03 PM, Mike Kienenberger wrote:
>>>>=20
>>>>> 2) Modern app servers restart and redeploy applications without
>>>>> restarting the app server.     Thus, the memory leak might be from =
a
>>>>> previous application instance or application deployment.   I think
>>>>> someone reported a possible Cayenne issue for that recently.
>>>>=20
>>>> I keep recommending to people this presentation by Mark Thomas from =
Tomcat project:
>>>>=20
>>>> Video with slides: =
http://www.infoq.com/presentations/Diagnosing-Memory-Leaks
>>>> Slides in PDF: =
people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf
>>>>=20
>>>> Even if you are not using Tomcat, but curious what happens to your =
memory, I still recommend it :) It is applicable to any Java app server =
and was an eye opener to me back in the day.
>>>>=20
>>>> Andrus
>>>>=20
>>>=20
>>>=20
>>=20
>=20
>=20