Ken Bowen wrote:
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.
All in all, it seems quite a messy problem.
To really detect that the client has gone while you are still doing
something for him, would require :
1) the ability to send from time to time some output to the client, which
a) would generate an error if the client has really gone and the
socket is closed in that direction
b) but would not disturb the client in any way if per chance it is
still there and waiting for an answer.
2) the ability to do this asynchronously with the real request
processing which is taking place in the meantime
3) a mechanism for, in case the client has gone in the meantime, telling
the process that is processing the request, that it can drop it and
discard whatever it wanted to output. Or alternatively, a method for
killing the request-processing process properly from outside.
4) a mechanism for cleaning this all up properly when the real response
output has been initiated.
5) the ability to set this up selectively only for requests likely to
take a certain time to process, so as not make the whole thing very
inefficient.
It would seem that there ought to be some low-level response-direction
socket flag that should be available, to tell whether the receiving end
has gone, without actually having to send anything from a higher-level
code module. But getting to that low-level socket data does not seem to
be so easy in Java, is it ?
I remember trying once to get back there starting from the
HttpServletResponse object, and not getting anywhere fast.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
