Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of cfineman@gmail.com designates
 64.233.184.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references;
        b=HZvVESyjqsgXWKpq45FBEkXbkSUEwZs5VvVfr8TTQOm6y5PJEvXYAigLU5VMTi62kHdBXhKphzTNyJunLSFgEicZJlviE+/v24ydx7xb4WjvHdF0HbNPt1yA1GOqyclrg1gOFtAfl9twhZ1O4mZUdf9wBMV7GRVCpokNIxrE6hM=
Message-ID: <914a054e0510031449p3daff65dy264dda03274a0d5@mail.gmail.com>
Date: Mon, 3 Oct 2005 14:49:28 -0700
From: Charles Fineman <cfineman@gmail.com>
Reply-To: Charles Fineman <cfineman@gmail.com>
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
Subject: Re: FAQ? shutdown.bat not killing java process on Windows
In-Reply-To: <43410A5A.7090204@mkodo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7347_10530811.1128376168617"
References: <914a054e0510020908r2318ebcasbd004f95da44ec7d@mail.gmail.com>
	 <43410A5A.7090204@mkodo.com>

------=_Part_7347_10530811.1128376168617
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thanks (to all). I had suspected this but all of the threads that were left
over (used eclipse) seemed like system threads. Turns out the culprit was a=
n
RMI server object that was being exported by the webapp (you can browbeat m=
e
over that in a different thread... I kept it for backwards compatibility).

At any rate, it turns out that Sun's RMI Distributed GC timer thread was
getting created as a non-daemon thread. There is, as you might expect, no
way to make this a daemon thread however I was able to unexport the Remote
object (indirectly of course :-) when the webapp get's shutdown.

This raises a question in my mind about the right way to do something in
tomcat/jws. I use a "manager servlet" that has an init (and now a destroy)
method to setup (tear down) resources for a webapp. I did it this way
because I wanted non-lazy initialization of the webapp's resources (i.e.
rather than waiting for the init method of one of the other servlets to be
called). I set the load-on-startup attribute to zero to ensure these get
loaded as soon as the webapp is loaded.

Is there another mechanism I ought to be using to initialize (arbitrary)
resources for my webapp?

On 10/3/05, Jon Wingfield <jon.wingfield@mkodo.com> wrote:
>
> Yep. It's a FAQ, but not in the FAQ.
>
> Tomcat not quitting generally means your webapp has started a non-daemon
> thread which does not exit when the webapp is destroyed. If so, shut
> them down in a ServletContextListener.
>
> If you aren't explicitly creating threads in your webapp then the usual
> culprits are database connections that haven't been closed (or any other
> client api to remote services that uses asynchronous messaging and/or
> keepalive semantics).
>
> To see a dump of the threads still active after you've run shutdown.bat
> do a CTRL-BREAK in the tomcat dos console.
>
> HTH,
>
> Jon
>
> Charles Fineman wrote:
> > I started Tomcat using startup.bat. Everything goes fine. I use
> > shutdown.batto bring it down. The server fields the request and shuts
> > down a bunch of
> > services (as evidenced by the messages I see). Sure enough, the server
> no
> > longer responds to any requests. Unfortunately, the java process does
> not
> > die.
> >
> > I have this problem whether I start Tomcat by hand or if I use the
> Sysdeo
> > Eclipse plugin.
> >
> > This problem has been a thorn in my side for some time but since it onl=
y
> > affects my development environment (we use it as a service in productio=
n
> and
> > there are no problems) and I can kill the process by hand, I've not
> worried
> > about it. It's annoying as heck though and I'm wondering if someone can
> shed
> > some light.
> >
> > I searched around but (surprisingly!!) I didn't find anything similar t=
o
> my
> > situation.
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>

------=_Part_7347_10530811.1128376168617--