Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E1F3473.9090604@christopherschultz.net>
Date: Thu, 14 Jul 2011 14:24:51 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Casual proposal for change to
 WebappClassLoader.clearReferencesThreads
References: <4E1EFBC7.1030508@christopherschultz.net>
 <4E1F070F.7030109@pidster.com> <4E1F0A4C.9060904@pidster.com>
In-Reply-To: <4E1F0A4C.9060904@pidster.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig31407DF6AF099E633744B508"

--------------enig31407DF6AF099E633744B508
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Pid,

On 7/14/2011 11:25 AM, Pid wrote:
> On 14/07/2011 16:11, Pid wrote:
>> On 14/07/2011 15:23, Christopher Schultz wrote:
>>> All,
>>>
>>> Is there any interest in having a configuration option for WCL that
>>> allows certain thread names to be ignored during webapp shutdown?
>>>
>>> See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussi=
on.
>>>
>>> It appears that there may sometimes be a race condition where the web=
app
>>> can't force the termination of an app-started thread that *will*
>>> eventually shut down. A minor change could alleviate printing a warni=
ng
>>> message on redeploy that may worry admins.
>>>
>>> I'm sure this would be useful to Terence, but I'm not sure if there's=

>>> wide applicability.
>>
>> Why does this help?  AFAICS he's not stopped the thread, he's just
>> stopped the scheduler.  If he wants the thread to stop he'll have to h=
it
>> .cancel() on the task.
>=20
> Actually, that might not be true.  (Teach me to skim the docs).
>=20
>=20
> The OP is really reporting that the timer.cancel() method doesn't block=

> & wait for all the running timer task threads to finish.

He's properly shutting-down the task scheduling service and all the
tasks finish before his code continues. The problem is a race condition
between the termination of the worker threads and the thread-checking
code in Tomcat.

> Interrupting a timer task thread might not be possible without jumping
> through hoops; the OP reports that if the run method is empty, there's
> no problem - but this would be expected because the run() cycle would b=
e
> short & therefore the timer task thread will win the race between
> contextDestroyed completing & the thread finishing.

I thought he said that, with an empty run method, he still needs to call
sleep() in order to avoid the race condition.

> If the thread takes longer (the OP reports ~0.5s) then
> contextDestroyed() wins and Tomcat reports threads down.
>=20
> Quartz suffers from the same problem (or did last time I looked).

The problem is that the OP can't get ahold of the Thread objects
themselves in order to do a join() on them. All tasks are cancelled,
successfully. His hands are tied by the API.

I'm trying to avoid the following progression:

1. TaskScheduler has a race condition, triggers a false alarm in Tomcat
2. IT staff, etc. are directed to ignore Tomcat warnings about threads
3. Tomcat starts reporting legitimate thread problems
4. Everyone ignores them because they have been directed to do so

My proposal is to be able to identify which threads have been determined
to be non-threatening, and suppress the warning.

-chris


--------------enig31407DF6AF099E633744B508
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iEYEARECAAYFAk4fNHYACgkQ9CaO5/Lv0PDy9QCfd5BrlFRmu3Lz+xdWVdQj4pVg
56QAn0tReSnCfvEpsXOvdAGEs1eSh/ME
=fOm1
-----END PGP SIGNATURE-----

--------------enig31407DF6AF099E633744B508--