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 >>> >> >> >
