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, > >> You will need something similar. > > > 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. > > Whats more, if I have implemented your filter, then why would I need to > create another one. > > Also, are these objects that hold on to my data objects? If so, then this is > a rather important issue. > > Thanks > Joe > > > > On Mar 14, 2012, at 9:59 AM, Andrus Adamchik wrote: > >> 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. >> >> 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() : >> >> http://svn.apache.org/viewvc/cayenne/main/branches/STABLE-3.0/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/conf/WebApplicationContextFilter.java?view=markup >> >> You will need something similar. >> >> Andrus >> >> >> On Mar 14, 2012, at 9:51 AM, Joe Baldwin wrote: >> >>> Andrus, >>> >>> 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() >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> So my question is what behavior would you expect, and what should my next >>> test be? >>> >>> Joe >>> >>> >>> On Mar 13, 2012, at 4:47 PM, Andrus Adamchik wrote: >>> >>>> >>>> On Mar 13, 2012, at 4:03 PM, Mike Kienenberger wrote: >>>> >>>>> 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. >>>> >>>> I keep recommending to people this presentation by Mark Thomas from Tomcat >>>> project: >>>> >>>> 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 >>>> >>>> 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. >>>> >>>> Andrus >>>> >>> >>> >> > >
