On 23.08.2017 09:48, Grigor Aleksanyan wrote:
Hi Simon,

If I understood your approach correctly, then this will work only if I am
the one that implements the client, right ? What about cases when client is
browser or curl, not my c++ app ?

Yes, that is one of the issues. Most browsers, after they send a request to a server, wait for about 3 minutes for an answer (which may be just one byte, but "something"). If they do not get the beginning of an answer within that timeframe, they will
- close the connection to the server
- automatically display some internal error page to the effect that "this server is not responding, please repeat your request later" The only way to stop this behaviour, at the browser level, is to have some "applet" builtin (in your previous application page), which "polls" the server regularly, to get some kind of "ack" back, which resets the browser's timer.

For expected long-running requests on the server, such a thing is usually part of the application, and shows itself in the browser as some kind of "progress bar", moving dots etc. That is /also/ a way to avoid that the user "panics" at not getting a response right away, and starts clicking left and right (which would also cause the browser to close that connection without waiting for the response).

All of this, is a legacy from the original design of HTTP, which was originally 
designed for
- client sends a request to a server, to get back "one thing" (a HTML page or a 
- the server sends back the requested resource (or an error if it doesn't have 
and then everyone is finished and the next such transaction is something totally disjointed and different. Over time, this original design has been "patched" a number of times, to accomodate more and more sophisticated interactions, as the WWW has "exploded" much beyond the original designers expectations. (And also as the capabilities of clients and servers have exploded). But one consideration has always been to maintain backward compatibility, so there are some basic principles which are difficult to modify, and application designers have to cope with them. Until someone invents - and manages to get adopted - something radically new and different, to replace HTTP. Websockets is a step, but it's still somewhat of a patch onto HTTP.

Thank you,

On Tue, Aug 22, 2017 at 1:13 PM, Simon De Uvarow <sdeuva...@gmail.com>

"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Tue, Aug 22, 2017 at 11:36 AM, André Warnier (tomcat) <a...@ice-sa.com>

On 22.08.2017 10:50, Grigor Aleksanyan wrote:


I have a web application (.war file) running under
It is a proxy application between my c++ client and server apps. Once
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

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
the server to produce some data to write, to detect this. I saw a couple
forums and mailing lists where people say that only way to do this, is
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 ?

You describe the problem well, and even the solution.

The problem is not at the Tomcat level, nor at the HTTP level. The
is at the lower TCP/IP level, and there is not much that Tomcat or HTTP
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
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,
that it is not data. So it could just respond with some kind of "ack",
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
: 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

And you are also right to say that it affects a lot of people and their
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

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

For cases that could have the described issue (HTTP request that may take
too long), I decided to create the "Interactive Task Manager".
The HTTP request starts a task to process something at server side, and
gets a quick response with the UUID of the task. Then the client can pool
asking if the task has finished.
When the task finishes, it stores the result as JSON in a temporal file.
When the client gets the result, the Interactive Task Manager deletes the
temporal file.
The Interactive Task Manager has it own thread pool to process the tasks.

It adds some overhead: HTTP requests asking for news + storing the result
to file + and reading it back. But it doesn't depend on configuration
changes, or hardware speed. It's robust.

I have the idea that HTTP requests should be resolved quikly (always less
than some seconds). If not, it's a bug, so we need to reimplement the
backend to fix it.

It's one possible solution. Maybe not the best.
Hope it helps.

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to