tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: multiple t hreads
Date Mon, 17 Jul 2006 16:47:17 GMT
Alan,

> 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.

> So you can't use this technique to run a batch job on 
> behalf of the user. In fact, running a long batch job will time out
> the webserver and abort the job.

You /can/ do a batch job on behalf of a user -- you just have to be
careful about it. For example, a user RELOADing the page many times will
spawn many threads on your server, which represents a potential DoS
risk. Resource management (such as threads) is usually best left to the
container unless you really know what you're doing.

> What I did to overcome that was to spawn a new Java virtual
> machine that ran apart from Tomcat.  To do this, I used an open
> source routine by Marty Hall.  You can exec "java classname" or
> exec a shell script or batch file that starts the JVM.

This is arguably worse than spawning a new thread to do this kind of
thing: you are subverting Java's protections and essentially allowing a
user to create a new process on your server.

You are better off creating a thread pool and re-using threads to
complete long-running operations. 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.

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.

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?!".

-chris



Mime
View raw message