6

Background

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 connection by closing the response, there's also a need for the client to be able to do this.

Problem

The client processes the InputStream in a separate thread, like this:

@Override
public void run() {
    try {
        for (int b = in.read(); b >= 0; b = in.read()) {
            char c = (char) b;
            // Do something with the character
            // ...
        }
    }
    catch (IOException e) {
    }
}

So when I call HttpURLConnection.disconnect() from the thread that initiated the connection (the important piece of information being that it's a different thread from the one processing the input), that call hangs indefinitely. I even left it overnight and it was still hanging. Even calling Thread.interrupt() didn't help.

Suggestions?

Steve
  • 8,066
  • 11
  • 70
  • 112

3 Answers3

5

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

Steve
  • 8,066
  • 11
  • 70
  • 112
  • If that's the case, I think noone should write such a code without using the available method. – stdout Dec 31 '18 at 11:51
2

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.

Alex Gitelman
  • 24,429
  • 7
  • 52
  • 49
  • Thanks. Only problem is that most of the time, the reading thread is blocked, so it doesn't have an opportunity to check the condition. There's no read method on `InputStream` that allows for a timeout. – Steve Nov 27 '11 at 12:19
  • you can use `available()` to see if anything is in the stream. If there is none, you can have a pause and recheck your condition after it so you never block on empty stream. – Alex Gitelman Nov 27 '11 at 17:26
  • Please see my answer - already acknowledged that fact and that it requires a poll/sleep/check cycle which is less than ideal. Thanks anyway. – Steve Nov 27 '11 at 17:48
  • @AlexGitelman cannot find the source code. do you mind updating your link? – stdout Dec 31 '18 at 11:48
0

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.

Jake Walsh
  • 3,669
  • 5
  • 22
  • 28