You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by mo...@comcast.net on 2017/01/06 22:08:08 UTC
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.
Re: Tomcat 8 memory leak (?) moving from GlassFish
Posted by mo...@comcast.net.
Thanks Chris,
I must be doing something wrong.
If I add either subscription-timeout-minutes or message-time-to-live (or both) to the remoting-config.xml file, I get HTTP status 500 (internal server error).
Is that the right file to place them in?
And, does timeout-minutes belong in services-config.xml?
----- Original Message -----
From: "Christofer Dutz" <ch...@c-ware.de>
To: users@flex.apache.org
Sent: Tuesday, January 10, 2017 5:28:46 AM
Subject: Re: Tomcat 8 memory leak (?) moving from GlassFish
Hi,
I can’t really say if you need all of them, I just noticed that if you don’t specify some of them no cleanup at all is done and that’s bad.
And yes we have released several versions of BlazeDs … the most recent one is 4.7.2
Chris
Am 09.01.17, 16:31 schrieb "modjklist@comcast.net" <mo...@comcast.net>:
Thanks so much Chris,
Has a stable BlazeDS 4.8.0 been released yet? Currently I'm using build=4.0.0.14931.
Thanks for summarizing the two (three?) parameters to set to help improve memory cleanup with BlazeDS.
Do I need to configure any of
timeout-minutes
subscription-timeout-minutes
message-time-to-live
if I don't use messaging? I only use BlazeDS to access remote objects. Will I still run into memory issues?
Which file does the
<flex-client>
<timeout-minutes>5</timeout-minutes>
</flex-client>
code get inserted into? I don't see that tag anywhere in my files.
----- Original Message -----
From: "Christofer Dutz" <ch...@c-ware.de>
To: users@flex.apache.org
Sent: Monday, January 9, 2017 1:26:00 AM
Subject: Re: Tomcat 8 memory leak (?) moving from GlassFish
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 "modjklist@comcast.net" <mo...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache flex users" <us...@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.
Re: Tomcat 8 memory leak (?) moving from GlassFish
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi,
I can’t really say if you need all of them, I just noticed that if you don’t specify some of them no cleanup at all is done and that’s bad.
And yes we have released several versions of BlazeDs … the most recent one is 4.7.2
Chris
Am 09.01.17, 16:31 schrieb "modjklist@comcast.net" <mo...@comcast.net>:
Thanks so much Chris,
Has a stable BlazeDS 4.8.0 been released yet? Currently I'm using build=4.0.0.14931.
Thanks for summarizing the two (three?) parameters to set to help improve memory cleanup with BlazeDS.
Do I need to configure any of
timeout-minutes
subscription-timeout-minutes
message-time-to-live
if I don't use messaging? I only use BlazeDS to access remote objects. Will I still run into memory issues?
Which file does the
<flex-client>
<timeout-minutes>5</timeout-minutes>
</flex-client>
code get inserted into? I don't see that tag anywhere in my files.
----- Original Message -----
From: "Christofer Dutz" <ch...@c-ware.de>
To: users@flex.apache.org
Sent: Monday, January 9, 2017 1:26:00 AM
Subject: Re: Tomcat 8 memory leak (?) moving from GlassFish
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 "modjklist@comcast.net" <mo...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache flex users" <us...@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.
Re: Tomcat 8 memory leak (?) moving from GlassFish
Posted by mo...@comcast.net.
Thanks so much Chris,
Has a stable BlazeDS 4.8.0 been released yet? Currently I'm using build=4.0.0.14931.
Thanks for summarizing the two (three?) parameters to set to help improve memory cleanup with BlazeDS.
Do I need to configure any of
timeout-minutes
subscription-timeout-minutes
message-time-to-live
if I don't use messaging? I only use BlazeDS to access remote objects. Will I still run into memory issues?
Which file does the
<flex-client>
<timeout-minutes>5</timeout-minutes>
</flex-client>
code get inserted into? I don't see that tag anywhere in my files.
----- Original Message -----
From: "Christofer Dutz" <ch...@c-ware.de>
To: users@flex.apache.org
Sent: Monday, January 9, 2017 1:26:00 AM
Subject: Re: Tomcat 8 memory leak (?) moving from GlassFish
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 "modjklist@comcast.net" <mo...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache flex users" <us...@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.
Re: Tomcat 8 memory leak (?) moving from GlassFish
Posted by Christofer Dutz <ch...@c-ware.de>.
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 "modjklist@comcast.net" <mo...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache flex users" <us...@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.
Re: Tomcat 8 memory leak (?) moving from GlassFish
Posted by mo...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache flex users" <us...@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.
Re: Tomcat 8 memory leak (?) moving from GlassFish
Posted by mo...@comcast.net.
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: modjklist@comcast.net
To: "apache users" <us...@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: modjklist@comcast.net
To: "apache flex users" <us...@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.
Re: Tomcat 8 memory leak (?) moving from GlassFish
Posted by mo...@comcast.net.
I should mention I'm using BlazeDS, which I'm assuming is creating connections(?).
----- Original Message -----
From: modjklist@comcast.net
To: "apache flex users" <us...@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.