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)
        <filter>
                <filter-name>CayenneFilter</filter-name>
                
<filter-class>org.apache.cayenne.conf.WebApplicationContextFilter</filter-class>
        </filter>
        <filter-mapping>
                <filter-name>CayenneFilter</filter-name>
                <url-pattern>/*</url-pattern>
        </filter-mapping>

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

Reply via email to