Java's HttpServletResponse doesn't have isClientConnected method

Question

I'm implementing a long poll http connection using java servlet.
How can I know that the http client is still active at any instance? Currently, what I do is to write a byte to the output stream and flush data. If there's an IO exception then the client is dead.
But in ASP.NET there is a property, Response.IsClientConnected which can find out if the client is active without writing anything to the output stream.
I want to know how if it is possible to develop in java servlet. I do not want to keep writing data into the http response stream as it may cost network.
Thanks in advance.

Answer 1

According to my concept, TCP knows.What concept is that? Which sockets API can you call to determine the current state?
to clarify it, i created a client server socket in which both client and server can send and recieve messages (using two threads in each side).
Now, when both are in waiting situation, i.e. sever socket is waiting for client's message and client socket is waiting for server's message. At this instance i kill the client (by closing the terminal in which it is runnung) the server socket immediately throws an IO excetion, i.e. it comes to know that its peer is dead.That doesn't 'clarify' your 'concept,' that describes an irrelevant experiment that merely confirms the obvious and doesn't apply to your original problem where your servers has finished reading the request and is busy creating the response.
Why isint the same possible in HTTP connection?See above.
I would like to see its exact specificationCan't say the exact implementationI didn't ask about the implementation. I asked about the specification. I've subsequently looked it up, and found numerous forum threads in which it is described as unreliable, which doesn't surprise me in the least, for the reasons I've given here.
At least i've verified via WireShark that it does not write anything from the inputstream while verifying isClientConnected.So therefore it can't even work as well as your existing code.
It seems to me that all it can do is tell you whether you have closed the connection yourself, or the next thing to be read is a FIN, or there has already been an incoming reset, and I doubt that it does all four of those things, as there is no API for the last one, and the 2nd one relies on looking for EOS while peeking the stream, which is fairly arcane. It certainly can't predict the future, which is basically what you're asking for, and what its own rather misleading specification suggests.
Let's be clear. There is no TCP protocol message that says 'the peer has finished reading and will return an error if you write'. You have to try the write and find out, as you've discovered. As there is no message, there cannot be any API that tells you whether it has been received. Ergo this thread is about nothing that exists