On 2/2/2016 2:49 AM, Yuval Schwartz wrote:
On Mon, Feb 1, 2016 at 7:36 PM, Terence M. Bandoian <tere...@tmbsw.com
<mailto:tere...@tmbsw.com>> wrote:
On 2/1/2016 10:12 AM, Yuval Schwartz wrote:
Hello Terence,
Thanks for the input.
I shutdown the ScheduledExecutorService in the
contextDestroyed method of
the app's ServletContextListener class as well.
I also call shutDownNow() followed by an if statement with
!awaitTermination() as the condition.
Are you sure that the new warning that I'm getting is also
related to the
ScheduledExecutorService?
The warning again is:
WARNING [main] org.apache.tomcat.util.net
<http://org.apache.tomcat.util.net>.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has
not fully
shutdown. Some application threads may still be running
I didn't find much information about http-apr-8080 on google.
When I do a thread dump while tomcat is running I see
http-apr-8080-exec-1,
http-apr-8080-exec-2,...http-apr-8080-exec-10.
I'm not sure what these do? Are these threads the same as
http-apr-8080
that is referenced in the warning?
How else can I go about debugging this message?
Thank you
Hi, Yuval-
I'm not sure the new warning is related to the way the
ScheduledExecutorService is stopped. You mentioned though that
the previous warning was related so I thought I'd share my
experience. Here's the code I used:
public void contextDestroyed( ServletContextEvent sce )
{
if ( executor != null )
{
boolean isTerminated = false;
executor.shutdown();
do
{
try
{
isTerminated = executor.awaitTermination(
1, TimeUnit.SECONDS );
}
catch ( InterruptedException ignore )
{
}
}
while ( !isTerminated );
executor = null;
Thread.yield();
Java docs say use of this method is rarely necessary...so I'm a little
hesitant to use it.
}
}
Notice the loop.
For the new warning, my suggestion would be to find out who owns
the thread in question. Can you do that with the profiler?
Thanks. I don't use a profiler. I'm using Jstack, and at the time the
application is running, when I do a thread dump, I don't see this
thread ("http-apr-8080").
I also did some testing on my development environment and printing the
threads right before tomcat shuts down prints some threads, but again,
none are named "http-apr-8080" (although some are named
http-apr-8080-exec-...).
Hope that helps.
-Terence Bandoian
On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian
<tere...@tmbsw.com <mailto:tere...@tmbsw.com>>
wrote:
On 2/1/2016 8:54 AM, Yuval Schwartz wrote:
Hello Mark,
I think that the issue below was related to the way I
was shutting down an
instance of ScheduledExecutorService.
I changed the way it is shutdown when the context is
destroyed...I will
update here if I don't receive any more warnings.
However, I now get a warning:
WARNING [main] org.apache.tomcat.util.net
<http://org.apache.tomcat.util.net>
.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool
[http-apr-8080] has not fully
shutdown. Some application threads may still be running
I am not sure if this is related or not?
When I do a heap dump with jstack I see
http-apr-8080-exec-[1-10] but I
don't see any thread named http-apr-8080.
Any ideas on how to trouble shoot this?
Thanks.
Hi, Yuval-
Where are you shutting down the ScheduledExecutorService?
I ran into a
similar problem trying to stop a ScheduledExecutorService
in the
contextDestroyed method of a ServletContextListener.
Adding a call to
Thread.yield() after the executor was terminated removed
the warning. To
terminate the executor, I used the shutdown() method
followed by a loop
with a call to awaitTermination().
-Terence Bandoian
On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz
<yuval.schwa...@gmail.com
<mailto:yuval.schwa...@gmail.com>
wrote:
On Sunday, 31 January 2016, Mark Thomas
<ma...@apache.org <mailto:ma...@apache.org>> wrote:
On 31/01/2016 08:06, Yuval Schwartz wrote:
Hellow Mark,
Thanks for the reply.
Follow up questions below.
On Fri, Jan 29, 2016 at 6:22 PM, Mark
Thomas <ma...@apache.org
<mailto:ma...@apache.org>> wrote:
On 29/01/2016 14:34, Yuval Schwartz wrote:
Hello,
tomcat version: 8.0.22
java: jdk1.8.0_05
server: Amazon Linux AMI
I get the following warning
message in my catalina log when I
undeploy a
web application:
*WARNING
[ContainerBackgroundProcessor[StandardEngine[Catalina]]]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads
The
web application [ROOT##002]
appears to have started a thread named
[pool-2-thread-1] but has failed
to stop it. This is very likely to
create
a memory leak. Stack trace of thread*
As you can see, for some reason, I
don't get a stack trace of the
thread.
Therefore, I have no idea how to debug
this warning.
This particular warning was
generated when tomcat detected an
unused
version and undeployed it (I set
undeployOldVersions="true").
Does anyone know how I can debug
this warning. How can I know more
about
this thread?
That looks like a thread from Commons
Pool (possibly via DBCP). The
only
way to be sure you have a leak or not is
to use a profiler. See
http://home.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf
<http://home.apache.org/%7Emarkt/presentations/2010-11-04-Memory-Leaks-60mins.pdf>
Is VisualVM a good profiler to start with
considering my system?
Sorry, don't know. Never used it. I use
YourKit, mainly because they
kindly donate free licenses to OpenSource
developers to use with their
OpenSource projects.
Thank you Mark,
I installed VisualVM as a profiler.
I can now see all of the threads that tomcat is
"using" (?not sure if
that's the correct term) (there's 35 live threads
and 33 daemon threads).
Do you have any recommendations for how I might
trouble shoot the
original
warning that I got? Would I do a "heap dump"?
I have restarted tomcat since the time of the
original warning message,
so
I can't expect to find the same thread, correct?
Any tips?
FYI: I never saw my cpu climbing or anything, I am
troubleshooting this
warning solely on seeing the "Warning" message. Is
this overkill? Should
I
wait until something more severe occurs? (I have
not yet gone live with
my
webapp but planned on doing so soon).
Thanks.
Mark
I would just like to confirm that this warning
is not something serious.
I am currently having a little trouble
running VisualVM (jstatd) from a
remote machine but can struggle with it a
little more to try to get it
working.
Thanks.
I used the manager app and clicked "find
leaks" but it said that there
were
none.
(Can someone also explain why I
have to be cautious when using this
feature
on production environments).
It triggers a full GC which may
(hopefully briefly) pause the entire
JVM.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail:
users-h...@tomcat.apache.org
<mailto:users-h...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail:
users-h...@tomcat.apache.org
<mailto:users-h...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail:
users-h...@tomcat.apache.org
<mailto:users-h...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
