tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Tomcat Crashes out of continuous servicing of stuck request
Date Fri, 04 Dec 2009 11:37:20 GMT
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
> 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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message