Chris,
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
Alan Meyer
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
