I\'m using HttpURLConnection on the client side to consume a response in an HTTP streaming (server push) situation. Although the server may close the co
It looks like this can't be done without altering the reading thread to poll using InputStream.available() and sleep for a short perdiod when there are no bytes available, all the while checking some flag to see if the thread should end.
The solution is to just use Apache HTTP Components. By encapsulating the code for a GET request inside one class, this can be quite easily integrated into existing code.
public class HttpGetConnection implements AutoCloseable {
public HttpGetConnection(String url) throws IOException {
client = new DefaultHttpClient();
get = new HttpGet(url);
response = client.execute(get);
entity = response.getEntity();
}
public InputStream getContent() throws IOException {
content = entity.getContent();
return content;
}
@Override
public void close() throws Exception {
get.abort();
try {
content.close();
}
catch (IOException e) {
}
}
private HttpClient client;
private HttpGet get;
private HttpResponse response;
private HttpEntity entity;
private InputStream content;
}
The loop in the original post can remain as is and the reading thread will die shortly after calling HttpGetConnection.close()
.
Another workaround is to wrap the input stream in a Channel and use that (Channels.newChannel
), as suggested in the workaround to JDK-4329256. That will cause the underlying input stream to be closed when the thread is interrupted. However, there is a comment in the JDK that its not really interruptible. In my testing it seems to work. I've asked here for more information.
If server does not close connection but stops sending data, in.read()
will block. Now, notice that the code for HttpURLConnection.HttpInputStream.close()
will attempt to read from the stream as well to determine that end of stream is reached (source code).
close()
, in turn, is called from disconnect()
. And you end up with your threads blocked.
So it appears that you need to alter your logic. I assume that you close connection based on some conditions. So instead of doing it in different thread check for conditions before reading next byte in the reading thread and then do disconnect.
And, by the way, Thread.interrupt()
is not going to help you as it will only interrupt threads waiting on monitors while yours is waiting on IO.