Chris,
Thanks. We do #1 routinely, usually setting the thread(s) up as workers
managing a queue. #2 can be problematic as you note: long-running db
queries or long graphics generation are hard to fit into this model
simply
because one is using someone else's monolithic code that makes no such
provisions. #3 is what I was wondering about. So far our long tasks
haven't
been terribly long, but some are reaching that (user-frustration)
boundary.
Cheers,
Ken
On Dec 15, 2009, at 2:12 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ken,
On 12/15/2009 1:52 PM, Ken Bowen wrote:
Are there any standard techniques that a /developer/ of such a long
running proccess could apply to wrap the process in a cocoon which
periodically updates a browser with (real) progress data, and at the
same time, such updates are verifications that the socket is still
live and the user hasn't gone away; if the user has gone away, that
would be detected and the wrapper would kill the process??
Uh, probably :)
You'd probably want to do a few things:
1. Use a thread pool. This allows you to use your own threads to
either
do the "real" work, or to manage the connections back to the client. I
recommend the former, and allowing Tomcat's threads to mostly sit idle
while the thread pool does your long-running business tasks.
2. All your tasks need to be gracefully interruptable. If you are
doing
long-running database queries, then I'm not sure what you could do,
since you're just waiting on the server. If you want to limit query
time, there are methods in JDBC that allow you to at least request a
time limit on a query (see Statement.setQueryTimeout), though that
won't
really help you out much because the query will simply be aborted
after
a certain amount of time.
One way to make these tasks gracefully interruptable is to have them
periodically check a "stop" flag that is accessible by the task
itself,
but also settable by, say, another thread. If the "stop" flag is ever
true, clean everything up and stop the task, preferably indicating to
the caller that the task was stopped instead of completing.
3. Have your webapp's code (running in the Tomcat-managed thread) poll
for activity. Something like this:
doGet() {
Future future = new Task(); // be creative: see java.util.concurrent
try {
while(!future.isDone()) {
try {
Object result = future.get(1, TimeUnit.SECONDS);
} catch (TimeoutException te) {
response.flush(); // does this work?
// now, just keep waiting...
}
}
// send good response to client
} catch (InterruptedException ie) {
future.cancel();
response.sendError();
} catch (IOException ioe) {
// client disconnected
future.cancel();
response.sendError();
} finally {
future.cancel(); // just in case
}
}
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksn354ACgkQ9CaO5/Lv0PAQCgCfQGNbT9xF4FZ2PewPnFE52m8S
BhoAni5ya2Yye8sO6YWjqjvB4Gxu79IU
=WF/0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
