Should connection.disconnect() be called normally?

[wmulligan]

I am looking at your latest 1.5.4 changes.

Should we be calling HttpUrlConnection.disconnect after every request? The documentation is a bit vague about this.

When we call disconnect(), what happens if we have not read the entire response body yet? Is it possible that we could lose part of the response if we call disconnect() direct after getInputStream()?

Thanks!

[swankjesse]

@wmulligan don't call disconnect until you're done with the connection. You can call it when you're done with the connection; it doesn't harm connection pooling or anything unless the disconnect is abrupt.

[wmulligan]

Just to confirm, when we call getInputStream() and receive the inputstream, has the entire response body been buffered/received? Or is the input stream a live stream from the server that will block when we read it?

[swankjesse]

You shouldn't call disconnect() until you're completely done with the connection. If you call disconnect early, your response body will be truncated.

[wmulligan]

Alright thanks for the reply. One more question, what happens if we don't call disconnect()? Will the connection still be recycled without calling disconnect?

Why I am asking these questions is b/c we make network calls on one thread, and do parsing on another thread, so I am trying to figure out how to pass the inputStream to the parser, while not killing the connection. If we don't need to call disconnect, then that would solve the issue.

[swankjesse]

You don't need to call disconnect. You do need to close the input stream containing the response body.