-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Terence,

On 7/12/2011 3:47 PM, Terence M. Bandoian wrote:
> executorService.shutdown();
> 
> try { while ( !executorService.awaitTermination( 1, TimeUnit.SECONDS
> ) );
> 
> Thread.sleep( 1000 ); } catch ( InterruptedException ie ) { }


We use a ThreadPoolExecutor (which is an ExecutorService) in one of our
projects, and we do something like the following:

            int counter = 0; // Only emit messages every 10 seconds
            while(true)
            {
                if(_executor.isTerminated())
                {
                    break;
                }
                else
                {
                    if(++counter > 9)
                    {
                        if(!_executor.isTerminated())
                        {
                            logger.info("Still waiting on "
                                        + (_executor.getQueue()
                                           .size() + 1)
                                        + " jobs to complete");
                        }

                        counter = 0;
                    }

                    // Sleep
                    try { Thread.sleep(1000); }
                    catch (InterruptedException ie) { /* do nothing */ }
                }
            }

This will test for completion every second, but only print warning
messages every 10 seconds that the service is waiting for the jobs to
complete.

I suppose we could even do _executor.awaitTermination(1, SECOND) to
jump-out a little early, but the point is that we loop waiting and also
print job counts, too. That may help you observe what is going on.

We don't run this in a webapp context, so we aren't ever having Tomcat
try to detect these threads or anything.

It's certainly possible that you are on the unfortunate end of a race
condition where Tomcat starts it's loose-thread detection before the job
thread has fully terminated and so the warning is spurious. Note that
awaitTermination() and isTerminated() methods are only documented to
return true when all jobs have completed and mention nothing about
destruction of the actual threads that perform the jobs.

You may be out of luck from an API perspective, so perhaps an arbitrary
Thread.sleep() may be your only option, here. You could, of course, tell
Tomcat not to check for this kind of thing and the message(s) will go
away. I think it's better to allow Tomcat to complain, but know that a
message about a particular thread (you can name your threads by
specifying a ThreadFactory) is spurious and that others should be
investigated.

I wonder if anyone would be interested in a regular expression for
thread names that could be used to ignore certain threads during this
loose-thread checking for cases like this.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4dyS0ACgkQ9CaO5/Lv0PAOpACfcPhCnHGhhC03dGcxKw5udCQZ
1NkAoKZEvqwIIYh3/sNqmdAJP7O7hKor
=HKaB
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to