You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Vance - <va...@gmail.com> on 2012/05/18 18:14:27 UTC

Threads in Tomcat

I'm maintaining a Web application for searching multiple wikis, this app
runs under Tomcat 6. I need to modify a servlet so it instantiates a
'Thread' subclass to perform a wiki availability check every so often, say
every 30 minutes. Given that I'm no expert on the use of threads, a
co-worker suggested the following questions to look into:

·         Does the spawned thread have a time limit imposed by Tomcat?

·         Does it take up worker thread space from other Tomcat threads?


I'd appreciate any help anyone could give w.r.t. these questions.

Re: Threads in Tomcat

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vance,

On 5/18/12 12:29 PM, Vance - wrote:
> The servlet I have in mind for modification is the one responsible
> for performing the search as well as for getting the next page of
> search results. If one or more of the wikis is unavailable, I want
> to display an error message on the search results page.

I'm not sure that's entirely relevant.

> The wiki availability check won't be done all the time, as I
> mentioned before, just every so often, say, every 30 minutes.

Again, not sure that's relevant. If you are going to do things
periodically, then the place to kick-off the thread is in a
ServletContextListener and not in a servlet.

> Why would using a ServletContextListener be better than using a
> servlet?

Because that's the most appropriate place to do it: servlets can be
started and stopped, started multiple times, run in parallel, etc. --
however the container wants to do things. ServletContextListeners are
well-defined to only be called on startup and shutdown.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+6myQACgkQ9CaO5/Lv0PCIWgCePuqidEy+iLnmzQTF5bNvJlBJ
ffIAoKvQ8Xp2v15Q7Xia9i1qlCmA2jWl
=kA23
-----END PGP SIGNATURE-----

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


Re: Threads in Tomcat

Posted by Vance - <va...@gmail.com>.
Chris, thanks for responding.

The servlet I have in mind for modification is the one responsible for
performing the search as well as for getting the next page of search
results. If one or more of the wikis is unavailable, I want to display an
error message on the search results page.

The wiki availability check won't be done all the time, as I mentioned
before, just every so often, say, every 30 minutes.

Why would using a ServletContextListener be better than using a servlet?


On Fri, May 18, 2012 at 12:20 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vance,
>
> On 5/18/12 12:14 PM, Vance - wrote:
> > I'm maintaining a Web application for searching multiple wikis,
> > this app runs under Tomcat 6. I need to modify a servlet so it
> > instantiates a 'Thread' subclass to perform a wiki availability
> > check every so often, say every 30 minutes.
>
> Suggestion: use a ServletContextListener, not a Servlet. Remember to
> terminate the thread in the destroy() method. Note that terminating a
> thread basically requires that you be able to communicate with the
> thread to tell it to shut down (i.e. don't call Thread.stop()): you
> need to have a Runnable that can be interrupted (using interrupt())
> and also knows that the interrupt needs to be terminal... so set a
> "shutdown" flag or something like that.
>
> > Given that I'm no expert on the use of threads, a co-worker
> > suggested the following questions to look into:
> >
> > ·         Does the spawned thread have a time limit imposed by
> > Tomcat?
>
> No.
>
> > ·         Does it take up worker thread space from other Tomcat
> > threads?
>
> No.
>
> Your thread will take up RAM and CPU time of course. Also, processes
> have thread limits and your thread will count against that.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+2dsYACgkQ9CaO5/Lv0PBT8ACgnUwG5KjDzTf9SYHtEM9iaYxJ
> dy8An1vGhmAjMhzgpvfXGVNMkDlQTPzA
> =nH91
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Threads in Tomcat

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vance,

On 5/18/12 12:14 PM, Vance - wrote:
> I'm maintaining a Web application for searching multiple wikis,
> this app runs under Tomcat 6. I need to modify a servlet so it
> instantiates a 'Thread' subclass to perform a wiki availability
> check every so often, say every 30 minutes.

Suggestion: use a ServletContextListener, not a Servlet. Remember to
terminate the thread in the destroy() method. Note that terminating a
thread basically requires that you be able to communicate with the
thread to tell it to shut down (i.e. don't call Thread.stop()): you
need to have a Runnable that can be interrupted (using interrupt())
and also knows that the interrupt needs to be terminal... so set a
"shutdown" flag or something like that.

> Given that I'm no expert on the use of threads, a co-worker
> suggested the following questions to look into:
> 
> ·         Does the spawned thread have a time limit imposed by
> Tomcat?

No.

> ·         Does it take up worker thread space from other Tomcat
> threads?

No.

Your thread will take up RAM and CPU time of course. Also, processes
have thread limits and your thread will count against that.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+2dsYACgkQ9CaO5/Lv0PBT8ACgnUwG5KjDzTf9SYHtEM9iaYxJ
dy8An1vGhmAjMhzgpvfXGVNMkDlQTPzA
=nH91
-----END PGP SIGNATURE-----

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


RE: Threads in Tomcat

Posted by Casper Wandahl Schmidt <ka...@gmail.com>.
A little late for the party but nonetheless:

I'm using Quartz for something similar. I use a framework that has a startup and shutdown hook. This I where I configure Quartz and launch the thread/worker (in startup hook) and shutting it down nicely (in shutdown hook). This way you don't have to worry about memory leaks when redeploying your webapp. As Tim mentioned you still have to take care of any concurrency between the availability check and the servlets accessing the Wikis though (my worker runs once a day and writes to a database, the webapp servlets then reads from the database).

Med venlig hilsen/Kind regards
Casper/Kalle

-----Original Message-----
From: Tim Watts [mailto:tim@cliftonfarm.org] 
Sent: 18. maj 2012 21:54
To: Tomcat Users List
Subject: Re: Threads in Tomcat

On Fri, 2012-05-18 at 12:14 -0400, Vance - wrote:
> I'm maintaining a Web application for searching multiple wikis, this 
> app runs under Tomcat 6. I need to modify a servlet so it instantiates 
> a 'Thread' subclass to perform a wiki availability check every so 
> often, say every 30 minutes. Given that I'm no expert on the use of 
> threads, a co-worker suggested the following questions to look into:
> 
Might want to study the classes & interfaces in java.util.concurrent instead of using a raw Thread.  Concurrency often ends up being trickier than it first appears and the classes & interfaces in this package were designed to handle a lot of these subtle details for you.  The Executors class in particular has some pre-built common configurations ready to instantiate.

> ·         Does the spawned thread have a time limit imposed by Tomcat?
> 
> ·         Does it take up worker thread space from other Tomcat threads?
> 
I believe the simple answer to these is No.  Which is to say I don't believe Tomcat per se enforces such limits.  However, it may be possible that an active SecurityManager could impose them.  Would be unusual though -- especially the 1st question.

> 
> I'd appreciate any help anyone could give w.r.t. these questions.



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


Re: Threads in Tomcat

Posted by Tim Watts <ti...@cliftonfarm.org>.
On Fri, 2012-05-18 at 12:14 -0400, Vance - wrote:
> I'm maintaining a Web application for searching multiple wikis, this app
> runs under Tomcat 6. I need to modify a servlet so it instantiates a
> 'Thread' subclass to perform a wiki availability check every so often, say
> every 30 minutes. Given that I'm no expert on the use of threads, a
> co-worker suggested the following questions to look into:
> 
Might want to study the classes & interfaces in java.util.concurrent
instead of using a raw Thread.  Concurrency often ends up being trickier
than it first appears and the classes & interfaces in this package were
designed to handle a lot of these subtle details for you.  The Executors
class in particular has some pre-built common configurations ready to
instantiate.

> ·         Does the spawned thread have a time limit imposed by Tomcat?
> 
> ·         Does it take up worker thread space from other Tomcat threads?
> 
I believe the simple answer to these is No.  Which is to say I don't
believe Tomcat per se enforces such limits.  However, it may be possible
that an active SecurityManager could impose them.  Would be unusual
though -- especially the 1st question.

> 
> I'd appreciate any help anyone could give w.r.t. these questions.