On 22.08.2017 10:50, Grigor Aleksanyan wrote:
Hi,
I have a web application (.war file) running under *apache-tomcat-7.0.52*.
It is a proxy application between my c++ client and server apps. Once HTTP
request (from the client) is received by web application, it propagates
request to the server and sends response back to the client once it is
ready. Server may need long time before it produces some data to send to
the client (also it can send data by chunks with really long delays etc.).
My question is.
*Is there a way to detect client disconnect before the time server has
something ready to be written to the output stream?* In case if server
writes something after client's disconnect, obviously I will get an
exception and can handle it properly. But my goal is to avoid waiting for
the server to produce some data to write, to detect this. I saw a couple of
forums and mailing lists where people say that only way to do this, is by
writing to outputstream. But in case of websockets I know that I can get
notifications that connection was closed by the client.
I believe this is a very common issue people face and there should be a
graceful solution for this for HTTP as well.
Can you please advice ?
Hi.
You describe the problem well, and even the solution.
The problem is not at the Tomcat level, nor at the HTTP level. The problem is at the lower
TCP/IP level, and there is not much that Tomcat or HTTP can do about it.
When a client establishes a TCP connection to a server, this is a "virtual" connection.
There is no hardware or physical line that is dedicated to this connection. In other
words, it exists only as long as the server and the client agree that it exists.
(And if there are any firewalls or proxies in-between, it is not even one connection, it
is multiple chained connections).
If the client just decides to "go away", without explicitly telling the server so, the
server side is totally unaware that the client has gone, until the server tries to send a
packet on the connection, and (some time after that) expects to receive an "ACK" and does
not get one.
In the case of websocket, you have a well-behaved client, that (supposedly) tells the
server when it is closing the connection. So the application could test this, by sending
some kind of "probe" from time to time, to check that the client is still there.
And the client would expect such a probe, and know that it is a probe, and that it is not
data. So it could just respond with some kind of "ack", that the server also would
interpret correctly.
But even then, if the client host were to just crash (or anything in-between, like a
firewall or a router e.g.) you would have the same issue : nothing is sent to the server
saying that the connection no longer exists, so the server thinks it is still there, as
long as it does not send anything.
And you are also right to say that it affects a lot of people and their
applications.
It is frustrating to e.g. start some long and heavy search in a database, and then when
the result appears, find out that there is nobody listening anymore (*).
There may be some good universal solutions to this, but so far I don't know of
any.
Fame awaits you, if you find one that can be universally applicable.
(*) and even if you knew that the client has gone, some tasks which you started in the
background, may not be so easy to stop in the middle either.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
