On 04.12.2009 11:41, Looijmans, Mike wrote:
...
Without trying to send something back to the client, there is
no way telling the client closed the window (or pressed
reload or switched to another URL).
I would expect the socket to be closed, which can be detected at the
server side. The exceptions I can think of are the client crashing or a
network disconnect.
Though apache probably detects the socket's close, it has little means
It detects the close only when trying to send something via the socket.
There's no monitoring of unused sockets. Although the server received
the FIN or RST packets and changes the state of the socket internally,
there'*s no application (=Apache) code checking that state when not
actually trying to use the socket. You could write such code, but it's
not there. The closed socket is detected once the server tries to read
from or write to it.
of informing the associated servlet because that is blocked waiting for
the response from the database.
Exactly. Even if the web server knew, you would still have to forward
the information to the naxt hop, e.g. Tomcat (and then also the
database). The communication between Apache and Tomcat (either via http
or via ajp) doesn't have any notification facility of the form "don't
proceed working on this request". It can only detect an error on top of
request and response communication. So here, once the app actually tries
to send something back, Apache will notice the closed socket to the
client, and then close the socket to the backend itself (at least in the
case of mod_jk) and then Tomcat notices the closed socket to the web
server and throws an error itself.
Depending on the database, it is usually also no use to try and stop -
the query will continue its work even though the requesting user is gone
on most DBMSes. So taking a slot in the webserver is not a big issue,
the DB is wasting far more resources on that user.
Other options to explore are dividing the big query into multiple
smaller ones, so that you can abort sooner. Use "INTO TEMP" to store
intermediates. That would give you the opportiunity to check whether the
client is still listening - and you could even give the client some
updates on progress, which may be considered a nice to have feature as
well.
Best of all would be to optimize the database and make those queries
faster, but I guess you must have valid reasons for not doing so.
M.
-- My reply ends here --
This message and attachment(s) are intended solely for use by the addressee and
may contain information that is privileged, confidential or otherwise exempt
from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this communication is strictly
prohibited.
If you have received this communication in error, please notify the sender
immediately by telephone and with a 'reply' message.
Thank you for your co-operation.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
