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) <a...@ice-sa.com> 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 > > -- ------------------------------ *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC. IT IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY E-MAIL OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS MESSAGE FROM YOUR SYSTEM. E-SIGNATURE NOTICE: Unless specifically set forth herein, the transmission of this communication is not intended to be a legally binding electronic signature, and no offer, commitment or assent on behalf of OneMarketData, LLC is expressed or implied by the sending of this email, or any attachments hereto.
