tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Meyer <>
Subject Re: multiple t hreads
Date Mon, 17 Jul 2006 20:46:01 GMT


Thank you for the excellent advice and suggestions.

>> When I tried to [spawn a new thread on behalf of the remote
>> user] on older versions of Tomcat (4.x), all output to the
>> user was suspended until _all_ of the threads completed.

> This was probably due to mismanagement of the thread; a new
> thread will run independently of your request handler thread,
> unless you call "join" on that thread, which will block the
> current thread until the "joined" thread completes.

I take it you've actually tried this and it worked for you.
Which version of Tomcat were you using?

I'm positive that I didn't call join to wait for completion of
the threads that I started.  Is it possible that earlier versions
of Tomcat did that beneath the covers, or perhaps that this was
configurable and our systems administrators (I wasn't
administering Tomcat myself) forced this to happen?

I agree that my technique was worse than spawning a thread.  I
didn't want the overhead of running two JVMs.  But, try as I
might (and I tried mightily hard), I wasn't able to make it work
on the installation of Tomcat that I was using.

I only allowed one batch job to run at a time, for just the
reasons you mentioned.  I wasn't worried about a malicious denial
of service attack since our server was running on an intranet for
vetted users, and I wasn't concerned about starting arbitrary
jobs since the users could only pick from my menu of jobs to run.
But I was worried about a user starting a long running job, not
seeing results right away, and starting it again and again.

> You are better off creating a thread pool and re-using threads
> to complete long-running operations.

Is this just to limit the number of threads that can run?

I wouldn't be much worried about the overhead of starting a new
thread since I already know I'm running a batch job which is
going to take a long time.  Starting a new thread is in the
noise, performance wise.

> You can have your long-running thread write some status to
> somewhere convenient (such as the user's session) so that
> subsequent requests can display some kind of status information
> each time. There's no need to worry about request timeouts,
> etc.

That's a very neat idea!  I never thought of anything like that.

> If possible, a better solution would be to actually run the
> batch job /as a batch job/ -- i.e. store the job in a
> database/file/whatever, and have another process come along and
> process that request as necessary.

Another excellent idea.  I thought of it and have used it on
other projects but, alas, the sys admins hated the idea of
running another daemon and I didn't want to fight with them.

> This is all academic, since I think the original question was
> something along the lines of "Does Tomcat actually work like an
> app server should?  with threads and everything? Does it?!".

Well, the original poster may not have learned anything from
this, but I certainly did.

Thanks again.


Alan Meyer

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message