aaime74 wrote:
...
Ok, but let's say Tomcat is capable of that. How does one check from
within the servlet that the connection has been dropped without writing
out anything?
I have been looking (starting at the HttpServletResponse object), trying
to follow the trail to see if one at some point can get hold of some
"Connection" object which would have some "isConnected" property. No
luck so far, but I am really not a java expert.
What I've tried so far is trying to block on the input stream
provided by the Http request and hoping it would throw an exception if
the client drop the conntection, but that does not work, the input
stream just return -1 to any "read" operation no matter if the client
is still connected or not.
Yes, but that is because each TCP connection really consists of two
separate parts or sides. For each "actor" (server and client), there is
one part that is the incoming connection, and another separate part that
is the outgoing connection (the sides being "crossed-over" in the middle
for the server and the client).
Each actor can close its own incoming or outgoing connection,
independently, without warning to the other part. (E.g., suppose it just
crashes). When that happens, the other side of that connection is left
"dangling" : basically, it does not known that the other side is "gone",
until it tries to send something on that connection, and the TCP stack
(deep down in the bowels of the underlying OS) returns an error, which
then filters back up all the way to your java OutputStream object.
In your case, what matters to you is the response output stream, not the
input stream, which could have been (validly) closed by the client
already, if it has no further use for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
