views:

107

answers:

1

I've developed a Webbapp that makes an extensive use of threads. We need to monitor some resources at fixed intervals and then act.

To achieve this, we've developed a ThreadManager that wraps one ScheduledThreadPoolExecutor. We allow any of the methods of the executor, we only use this manager to make sure everybody uses the same instance of thread pool (the manager is an Singleton...)

Then, when we close the context, we have a ServletContextListener that takes care of properly closing the executor:

 ejecutor.shutdown();
 try
 {
      ejecutor.awaitTermination(10, TimeUnit.SECONDS);
 }
 catch (InterruptedException ie)
 {
     Thread.currentThread().interrupt();
 }
 System.out.println("Llamo al shutdownnow");
 ejecutor.shutdownNow();
 ejecutor = null;

But then, when we close tomcat/unload the context we get lots of errors saying:

GRAVE: The web application [/qsys] appears to have started a thread named [pool-4-thread-1] but has failed to stop it. This is very likely to create a memory leak.

If we monitor the executor by asking the number of active threads, after the shutdown, it keeps on saying that there are no more active threads, but we keep on finding the same error on tomcat.

Any ideas?

Update: more info provided The threads that hang are those that are scheduled in the Executor. All of them override interrupt() so that it goes like:

System.out.println("Me intentan interrumpir!!");
run = false;
super.interrupt();

Then, during the contextDestroyed I execute the shutdown already mentioned... but the system out from the interrupt doesn't even get printed!

The executor has the ExecuteExistingDelayedTasksAfterShutdownPolicy set to false...

Still keep threads alive...

A: 

Finally, I found out something:

Every single time I use a ScheduledThreadPoolExecutor tomcat fails to close the pooled threads on undeploy / close / restart, thus causing a possible memory leak (it should be no problem, for tomcat fails to close them, but after it kills them, so no problem, but the customer wouldn't allow it...), while other servers worked like a charm...

In fact, I created a ScheduledThreadPoolExecutor with core size of 25, then shutdown it (nothing running or scheduled) and tomcat still failed to clean pooled threads.

So my solution was to use a Timer, while I wait for a patch... (It happened with tomcat 6.0 & jdk 1.5.0_22)

SoulWanderer