Re: Detect client disconnect in Tomcat

[Simon De Uvarow]

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

On Wed, Aug 23, 2017 at 8:33 AM, André Warnier (tomcat) 
wrote:

> 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 file)
> - the server sends back the requested resource (or an error if it doesn't
> have it)
> 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.
>
>
Yes, you have to implement the "retry/pooling" logic in the client.
Today , browsers running javascript apps make this possible.

The client side is like:

1- POST start big job URL
 response comes with job id

2- while (!end) {
   GET job result URL + job id
response comes with false or with the job result
   if (response comes with false) {
   sleep 10 seconds
   }  else {
   end = true;
   manage result of big job
}
}

That is something you can do with javascript and modern browsers. Search
for AJAX: Async HTTP requests.

Re: Detect client disconnect in Tomcat

[tomcat]

On 23.08.2017 09:43, Grigor Aleksanyan wrote:

Hi André,

Thanks for your detailed response,  I really appreciate your help. I see
what you mean and have a couple of more question regarding to this topic.

I was looking at possibilities to use Spring framework's evening facilities
to register *TcpConnectionClose *events listener in my web application
using *org.springframework.integration.ip.tcp.connection.TcpConnectionCloseEvent
*and *ApplicationListener *classes.

I was hoping to get *TcpConnectionClose *events when remote client socket
disconnects. In this case I hoped to to get these events in my listener
class and use connection ids to do proper cleanup. However I wasn't able to
receive *TcpConnectionCloseEvent*-s from Tomcat's connector port as I am
not the one that initializes Server listening on HTTP connector port
(wasn't able to register listener for it) and client side socket is not
created by me in java side to call close and receive close events .

However, I was able to receive *TcpConnectionClose *events when I created
my own, separate server, registered listener for TcpConnectionClose events
for it, created a client socket, connected it to my server's port (again in
java not c++) and *explicitly* called close for that socket. Do you think
that this evening approach doesn't have potential to work for Tomcat's HTTP
connector server and I should not look into this further to make it work ?

Also one more consideration, I was thinking about re this

In case when one uses simple TCP (not HTTP) client/server protocol, once
server calls *recv *function and client side is disconnected, error code is
returned on the server.

*I wonder why in case of Tomcat calling read on requests's InputStream
doesn't throw when client is disconnected ?*

My initial assumption was the following. As I use *HTTP 1.1, *which
supports persistent connections and pipe lining of the requests (client
need not wait to receive the response for one request before sending
another request on the same connection), Tomcat should call *recv *on the
handle to receive new requests from the same remote client's socket (untill
it sends Connection: Close header). However my tests show that
*doFilter *function
is not called second time until *doFilter *called for the first request
(from the same connection) is finished.

*Is this done by design to make sure that server sends responses (on a
given connection) in the same order that it received the corresponding
requests?*

And what happens when I call *HttpServletRequest.getInputStream().read(...)* in
doFilter function, when remote client that has submitted ongoing request
was disconnected. My feeling is that Tomcat accepts connection from the
client (receives a socket handle to read requests from), reads first
request from accepted connection and propagates request to doFilter
function (without passing actual server side handle). So
*HttpServletRequest *is completely separated from the underlying socket,
  thus calling read on request's input stream doesn't actually call *recv *on
TCP socket handle. Am I right ? If yes this could explain why calling read
doesn't throw.

But if pipe lining is supported, from what I understand, server should keep
calling *recv *on accepted handle (somewhere in the low level code) thus
client's disconnect should return SOCKET_ERROR, and this somehow should be
visible in Tomcat (let's first assume there are no middleware proxies )?
What do you think, do I miss something ?



Although (I repeat) this is not really my area of expertise, I think that I should warn 
you of a couple of aspects :
- a TCP socket is a bi-directional "thing", which each side having its "sending half" and 
its "receiving half". And I believe that it is perfectly protocol-compliant, for a client 
to close its "sending part", while still keeping its "receiving part" open and reading 
from it.
So, as far as I understand, if the server detects that the client's "sending part" is now 
closed (iow a *recv* triggers an "end-of-file" eror), it does not mean that the client has 
gone away. It just means that the client has nothing more to send.
But the client may still be reading its "receiving part", until it gets the full response 
to a previous request.
- the "HTTP keepalive" and "pipelining" functionality, is meant to avoid the overhead of 
establishing, and then later tearing down, a TCP connection between client and server, for 
each request. That was introduced at a time when such procedures were comparatively time- 
and resource-consuming (several packets being exchanged back and forth), and lines were 
comparatively slow. So for example retrieving a HTML page containing 10 image pointers, 
resulted in 11 succesive connections being created and torn down.
The "keepalive" instead, allows to send all 11 requests, and 11 responses, one after the 
other, on the same unique TCP/HTTP connection.  That saves 10 TCP setup/teardown sequences.
But that does not mean that the client does not 

Re: Detect client disconnect in Tomcat

[tomcat]

On 23.08.2017 10:52, Grigor Aleksanyan wrote:

I see André, thanks for clarifications. By the way, have you noticed my
previous email about TcpConnectionCloseEvents of Spring and question about
HttpRequests handling in Tomcat? Do you have any thoughts about what I
stated there? I would highly appreciate any information regarding these
points.


I am afraid that this is far beyond my expertise, and maybe someone else can 
take over here ?



Thank you,
-Grigor

On Wed, Aug 23, 2017 at 9:33 AM, André Warnier (tomcat) 
wrote:


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 file)
- the server sends back the requested resource (or an error if it doesn't
have it)
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,
-Grigor

On Tue, Aug 22, 2017 at 1:13 PM, Simon De Uvarow 
wrote:

"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) 
wrote:

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, 

Re: Detect client disconnect in Tomcat

[Grigor Aleksanyan]

I see André, thanks for clarifications. By the way, have you noticed my
previous email about TcpConnectionCloseEvents of Spring and question about
HttpRequests handling in Tomcat? Do you have any thoughts about what I
stated there? I would highly appreciate any information regarding these
points.

Thank you,
-Grigor

On Wed, Aug 23, 2017 at 9:33 AM, André Warnier (tomcat) 
wrote:

> 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 file)
> - the server sends back the requested resource (or an error if it doesn't
> have it)
> 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,
>> -Grigor
>>
>> On Tue, Aug 22, 2017 at 1:13 PM, Simon De Uvarow 
>> wrote:
>>
>> "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) 
>>> wrote:
>>>
>>> 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 

Re: Detect client disconnect in Tomcat

[tomcat]

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 
file)
- the server sends back the requested resource (or an error if it doesn't have 
it)
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,
-Grigor

On Tue, Aug 22, 2017 at 1:13 PM, Simon De Uvarow 
wrote:


"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) 
wrote:


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 

Re: Detect client disconnect in Tomcat

[Grigor Aleksanyan]

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 ?

Thank you,
-Grigor

On Tue, Aug 22, 2017 at 1:13 PM, Simon De Uvarow 
wrote:

> "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) 
> wrote:
>
> > 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
> >
> >
> 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 

Re: Detect client disconnect in Tomcat

[Grigor Aleksanyan]

Hi André,

Thanks for your detailed response,  I really appreciate your help. I see
what you mean and have a couple of more question regarding to this topic.

I was looking at possibilities to use Spring framework's evening facilities
to register *TcpConnectionClose *events listener in my web application
using *org.springframework.integration.ip.tcp.connection.TcpConnectionCloseEvent
*and *ApplicationListener *classes.

I was hoping to get *TcpConnectionClose *events when remote client socket
disconnects. In this case I hoped to to get these events in my listener
class and use connection ids to do proper cleanup. However I wasn't able to
receive *TcpConnectionCloseEvent*-s from Tomcat's connector port as I am
not the one that initializes Server listening on HTTP connector port
(wasn't able to register listener for it) and client side socket is not
created by me in java side to call close and receive close events .

However, I was able to receive *TcpConnectionClose *events when I created
my own, separate server, registered listener for TcpConnectionClose events
for it, created a client socket, connected it to my server's port (again in
java not c++) and *explicitly* called close for that socket. Do you think
that this evening approach doesn't have potential to work for Tomcat's HTTP
connector server and I should not look into this further to make it work ?

Also one more consideration, I was thinking about re this

In case when one uses simple TCP (not HTTP) client/server protocol, once
server calls *recv *function and client side is disconnected, error code is
returned on the server.

*I wonder why in case of Tomcat calling read on requests's InputStream
doesn't throw when client is disconnected ?*

My initial assumption was the following. As I use *HTTP 1.1, *which
supports persistent connections and pipe lining of the requests (client
need not wait to receive the response for one request before sending
another request on the same connection), Tomcat should call *recv *on the
handle to receive new requests from the same remote client's socket (untill
it sends Connection: Close header). However my tests show that
*doFilter *function
is not called second time until *doFilter *called for the first request
(from the same connection) is finished.

*Is this done by design to make sure that server sends responses (on a
given connection) in the same order that it received the corresponding
requests?*

And what happens when I call *HttpServletRequest.getInputStream().read(...)* in
doFilter function, when remote client that has submitted ongoing request
was disconnected. My feeling is that Tomcat accepts connection from the
client (receives a socket handle to read requests from), reads first
request from accepted connection and propagates request to doFilter
function (without passing actual server side handle). So
*HttpServletRequest *is completely separated from the underlying socket,
 thus calling read on request's input stream doesn't actually call *recv *on
TCP socket handle. Am I right ? If yes this could explain why calling read
doesn't throw.

But if pipe lining is supported, from what I understand, server should keep
calling *recv *on accepted handle (somewhere in the low level code) thus
client's disconnect should return SOCKET_ERROR, and this somehow should be
visible in Tomcat (let's first assume there are no middleware proxies )?
What do you think, do I miss something ?

Thank you,
-Grigor

On Tue, Aug 22, 2017 at 12:36 PM, André Warnier (tomcat) 
wrote:

> 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 

Re: Detect client disconnect in Tomcat

[Simon De Uvarow]

"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) 
wrote:

> 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
>
>
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.

Re: Detect client disconnect in Tomcat

[tomcat]

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