Hi,

I am using that combination and it’s working quite fine. However I already knew 
you were using BlazeDS, from your first post as I know that there are severe 
issues in the cleaning up of resources. 
Unfortunately the managing of message queues and the cleaning up code in 
BlazeDS is a nightmare. I did find out however that if you explicitly set a 
timeout. I just did a ponymail search and I guess this post of mine should help 
you:
https://lists.apache.org/thread.html/b2aba6fc94490bf025f7edabc164a99689b7b0c7f66d0bb15043e5c0@1438161589@%3Cdev.flex.apache.org%3E

Chris

Am 07.01.17, 05:15 schrieb "modjkl...@comcast.net" <modjkl...@comcast.net>:

    Anyone using Flex+BlazeDS+Tomcat? 
    
    If so, stop Tomcat ($CATALINA_HOME/bin/shutdown.sh) and look at the log at 
$CATALINA_HOME/logs/catalina.out. 
    
    Do you see a SEVERE error for memory leak when Tomcat stops? 
    
    ----- Original Message -----
    
    From: modjkl...@comcast.net 
    To: "apache users" <users@flex.apache.org> 
    Sent: Friday, January 6, 2017 3:22:21 PM 
    Subject: Re: Tomcat 8 memory leak (?) moving from GlassFish 
    
    The Tomcat support community replied with the following. I'm thinking 
anyone using BlazeDS with Tomcat should see the same issue. Anyone know how to 
resolve? 
    
    -------tomcat comments follow---------- 
    
    If all goes well, this leak will be handled by Tomcat and your service 
    won't suffer for it. That said, you should fix the problem because 
    cleaning-up messes is wasteful if the mess wasn't necessary in the 
    first place. 
    
    The leak itself is coming from your application or one of the 
    libraries it's using. The solution will be to find and fix that leak. 
    
    I would start by asking the Apache Flex people what the 
    SerializationContext is for, and how to remove ThreadLocal values from 
    shared threads (such as those in a servlet environment). 
    
    It's possible you are using the Flex framework in a way that is not 
    conducive to a servlet environment, but that a few changes could make 
    it safer to use. 
    
    ----- Original Message ----- 
    From: modjkl...@comcast.net 
    To: "apache users" <users@flex.apache.org> 
    Sent: Friday, January 6, 2017 2:12:59 PM 
    Subject: Re: Tomcat 8 memory leak (?) moving from GlassFish 
    
    I should mention I'm using BlazeDS, which I'm assuming is creating 
connections(?). 
    
    ----- Original Message ----- 
    
    From: modjkl...@comcast.net 
    To: "apache flex users" <users@flex.apache.org> 
    Sent: Friday, January 6, 2017 2:08:08 PM 
    Subject: Tomcat 8 memory leak (?) moving from GlassFish 
    
    In the processing of moving my Flex 4.12 web app from GlassFish 3.1.2 to 
Tomcat 8.5.9, I observe the following SEVERE error in the tomcat log. Has 
anyone seen this before, and if so, recommend how to address it? 
    
    
    
    06-Jan-2017 13:49:07.644 SEVERE 
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] 
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks 
The web application [myApp] created a ThreadLocal with key of type 
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@4d6e6d7b]) and a value of 
type [flex.messaging.io.SerializationContext] (value 
[flex.messaging.io.SerializationContext@66135428]) but failed to remove it when 
the web application was stopped. Threads are going to be renewed over time to 
try and avoid a probable memory leak. 
    
    
    

Reply via email to