Persistent Httpurlconnection in Java

Persistent HttpURLConnection in Java

According to the documentation here, HTTP persistence is being handled transparently in Java, although it gives you the options to control it too via http.keepAlive and http.maxConnections system properties.

However,

The current implementation doesn't
buffer the response body. Which means
that the application has to finish
reading the response body or call
close() to abandon the rest of the
response body, in order for that
connection to be reused. Furthermore,
current implementation will not try
block-reading when cleaning up the
connection, meaning if the whole
response body is not available, the
connection will not be reused.

Take a look at the link and see if it really helps you.

Persistent HTTP connection Java

In HTTP 1.0 there are no official specifications regarding the idea of persistent connections. For a persistent connection to work the client requests the connection to be kept opening by the addition of the Connection header as such:

Connection: Keep-Alive

If the server decides that the connection should be kept-alive (i.e. not closed) it to should respond with the header:

Connection: Keep-Alive

followed by keeping the connection alive for whatever defined period of time it chooses. Please note that the keep alive "feature" is not a official protocol feature of HTTP 1.0 and thus servers are not required to facilitate the client's request should the client request it.

In HTTP 1.1 it became implicit of persistent connections so if you see this happening on a server responding with HTTP/1.1 headers suspect that the server isn't adhering to HTTP 1.1 standards (unless the server explicitly responds with a Connection header with the value of Close).

In any case however there is a timeout period as defined by the server in which subsequent requests should be sent in by or else the connection is dropped. This is to prevent a spam of unclosed connections should clients drop without properly closing the connection.

The Java HttpURLConnection object attempts to reuse the TCP connection but upon failure will simply fall back to creating a new TCP connection.

Should I call disconnect() method of HttpUrlConnection when using non persistent connections in Java?

Connection: close means, it wants that client must be close the
connection when receive the chunked data. Am I right?

Not exactly. A Connection: close header in an HTTP message is informative, not prescriptive. It advises the receiver that the server intends to close the connection after sending the response (see RFC 7230, section 6.1). The user is not obligated to take specific action in response, but it may save itself some time by not attempting any further communication over that connection after receiving the HTTP payload. In practice, however, yes, after receiving the response, the client should close the application-layer connection on its end, too, for until it does, it will tie up associated system resources for no good reason.

But none of that is really your concern if you're working with an HttpURLConnection and / or the InputStream obtained from one. Per its documentation:

Each HttpURLConnection instance is used to make a single request but
the underlying network connection to the HTTP server may be
transparently shared by other instances. Calling the close() methods
on the InputStream or OutputStream of an HttpURLConnection after a
request may free network resources associated with this instance but
has no effect on any shared persistent connection. Calling the
disconnect() method may close the underlying socket if a persistent
connection is otherwise idle at that time.

That is, HttpURLConnection manages the details of persistent connections for you.

You continue,

Or, connection not closed because of data is streaming(server sends
chunked data each time, I'm not send get request to the server at each
time. Or is this done in the background?).

It seems that you simply mean that the server does not specify a content-length, and sends a response of indeterminate length over an extended period of time. In that case, the Connection header probably hasn't much practical relevance.

So, connection is not
closing at any time until I close the inputStream.close() method.
Right?

The server will not ordinarily close the connection at its end until it has sent the complete response. If, in principle, the response has unbounded length, then there is no reason to expect the server to initiate a connection closure from its end other than server shutdown or failure.

Also, if server is down at any time, http url connection will be
thrown the IOException.

Maybe. If the attempt to establish a connection in the first place fails, then you can expect an IOException of some flavor. If the server goes down while delivering the response then you might get an exception, but you might also just see the end of the stream.

In this case, Must I call the disconnect()
method of the http url connection? Or, should I call just
inputStream.close()?

You do not ever need to disconnect(), and if you do then it is merely advisory, as described in the docs quoted above. If you reach the end of the stream then you should indeed close it. If an IOException is thrown while you are reading the stream then it's probably best to attempt to close() the stream, but be prepared for that to fail, too, as the stream might be in an inconsistent state.

How can I close the http url connection safely at any time?

Once you've actually connected an HttpURLConnection instance to the underlying resource, closing its stream(s) should be enough to indicate that you're done with it. Before you've connected, you don't need to do anything at all.

Android HttpUrlConnection w Persistent Connection

Solved With Cookies

After days / hours of working on this I found that persistent connections (http.keepalive) with HttpUrlConnection is not all it's cracked up to be:

1) You need to make sure the InputStream and HttpUrlConnection are closed before you can reuse the connection and even then it may not always be reusable.

2) Open TCP connections can be resource hogs.

After finding & testing the idea of using cookies with HttpUrlConnection I decided to go that route as it's fundamentally more sound and performs better than my original idea.

---

Related Topics