Return-Path: X-Original-To: apmail-cayenne-user-archive@www.apache.org Delivered-To: apmail-cayenne-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0A4319B3F for ; Wed, 14 Mar 2012 18:09:23 +0000 (UTC) Received: (qmail 93476 invoked by uid 500); 14 Mar 2012 18:09:22 -0000 Delivered-To: apmail-cayenne-user-archive@cayenne.apache.org Received: (qmail 93457 invoked by uid 500); 14 Mar 2012 18:09:22 -0000 Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cayenne.apache.org Delivered-To: mailing list user@cayenne.apache.org Received: (qmail 93447 invoked by uid 99); 14 Mar 2012 18:09:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Mar 2012 18:09:22 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [209.86.89.66] (HELO elasmtp-spurfowl.atl.sa.earthlink.net) (209.86.89.66) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Mar 2012 18:09:16 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Er+OEqA5FNIxLtJMqHvusvKu2audB25YZ2zt/QjTcNWI8Lp2hfwcYGCv4wYu1oT/; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.176.13.146] (helo=[192.168.1.44]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1S7sd5-000411-4r for user@cayenne.apache.org; Wed, 14 Mar 2012 14:08:55 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: Memory Usage Problem with Tomcat From: Joe Baldwin In-Reply-To: Date: Wed, 14 Mar 2012 14:08:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48725E9F-F224-45B2-8C14-53994D83F8EE@earthlink.net> References: <8CB6B941-D04C-4F90-9416-6E410139C9D1@earthlink.net>

<8B077C09-C2A7-41B1-B127-4E25D0506A97@objectstyle.org> <3A198600-C6C2-4312-9525-1DBDB7B33561@earthlink.net> To: user@cayenne.apache.org X-Mailer: Apple Mail (2.1257) X-ELNK-Trace: 74aacf41df18ac9f85338a7d01cb3b6a7e972de0d01da9401020e519ef98e83fa8ad606f4016176b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.176.13.146 X-Virus-Checked: Checked by ClamAV on apache.org Andrus, that is a rather large amount of work, since I use TextWrangler Editor = (i.e. no IDE and not debugger). If you have a recommendation for an = opensource debugger, then I will give it a shot. (I am one of the few = people who thinks Eclipse is annoying. :) ) In the interim, here is my web.xml code (which I added a *long* time ago = - which appears to me to be the current methodology) CayenneFilter = org.apache.cayenne.conf.WebApplicationContextFilter

CayenneFilter

What in your experience would lead to the filter destroy method not = being called? Is there another library that could be holding on to a = reference? Thanks, Joe On Mar 14, 2012, at 1:44 PM, Andrus Adamchik wrote: > 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. >=20 > Andrus >=20 >=20 > On Mar 14, 2012, at 12:43 PM, Joe Baldwin wrote: >=20 >> 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 >=20