I am new to Java and HttpURLConnection. Should I close the opened IO streams before dropping the connection. If I close the streams, should I need to drop the connection as well? Which is the proper way of implementation?
try {
String uri = "http://localhost:8081/RESTEASY/saju/post/text";
URL url = new URL(uri);
connection =
(HttpURLConnection) url.openConnection();
connection.setRequestMethod("POST");
connection.setRequestProperty("Accept", "text/plain");
connection.setRequestProperty("Content-Type", "text/plain");
connection.setDoOutput(true);
OutputStream os = connection.getOutputStream();
//bla bla
System.out.println(connection.getResponseCode());
InputStream iStream = connection.getInputStream();
//bla bla
} catch (MalformedURLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}finally{
// os.close(); - IS THIS REQUIRED
// iStream.close(); - IS THIS REQUIRED
connection.disconnect();
}
}
Yes you need to close the inputstream first and close httpconnection next. As per javadoc. 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.
URLConnection is the base class. HttpURLConnection is a derived class which you can use when you need the extra API and you are dealing with HTTP or HTTPS only. HttpsURLConnection is a 'more derived' class which you can use when you need the 'more extra' API and you are dealing with HTTPS only.
The method is used to enable streaming of a HTTP request body without internal buffering, when the content length is not known in advance. The method is used to enable streaming of a HTTP request body without internal buffering, when the content length is known in advance.
You should call close()
on the input/output/error streams when you are finished using them.
Disconnect is more complicated. According to the javadoc for disconnect()
:
"Indicates that other requests to the server are unlikely in the near future."
This is recognizing the fact that HTTP 1.1 spec has a "persistent connection" feature that allows the same TCP/IP connection to be used in a sequence of requests to the same server. (This happens transparently.) When you call disconnect
, it is likely to be taken as a hint to close the connection.
So from a resource and performance perspective:
disconnect
if you aren't likely to send another request to the same server, If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With