United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4143518 : Need ability to set socket options on URLConnection

Details
Type:
Enhancement
Submit Date:
1998-05-28
Status:
Closed
Updated Date:
2003-10-08
Project Name:
JDK
Resolved Date:
2003-10-08
Component:
core-libs
OS:
generic,linux,solaris_2.6,windows_98,windows_nt,windows_2000
Sub-Component:
java.net
CPU:
generic,x86
Priority:
P4
Resolution:
Duplicate
Affected Versions:
1.1.6,1.2.2,1.3.0,1.3.1,1.4.0,1.4.0_01,1.4.1
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

Description

Name: diC59631			Date: 05/28/98


Enhancement request.  Need ability to set
socket options on URLConnection class or a way
to get the underlying socket.  Most useful for
long lived http connections which are needed to
get through most firewalls.  Socket Timeout is
the one I need most.
(Review ID: 32523)
======================================================================

Name: tb29552			Date: 03/24/2000


java version "1.3.0rc1"


I would like to use URLConnection to allow my applet to communicate
efficiently with my servlet server.  In order to get around firewalls and to use
the browser's SSL encryption mechanisms, I am using standard HTTPS "request"
type communications.  However, for efficiency's sake, I'd like the connection to
remain open with a Keep-Alive connection.  The trouble is that there is no way
that I can see in the JDK to dynamically set the client's KeepAlive timeout
setting.  I'd like to be able to set it for say, 5 minutes.  Unfortunately, the
timeout setting seems to be implementation dependent, and the Java 1.3RC1
plug-in seems to have a very short Keep-Alive setting (< 5 seconds).  If there
were a way in URLConnection or in another class to set the system's Keep-Alive
setting, it would be very helpful.
(Review ID: 102814)
======================================================================

Name: tb29552			Date: 05/01/2000



Under "Evaluation" for this feature request, 4143518, the
comment is that the feature could be implemented in some
sort of SocketFactory mechnism like the way JSSE implemented
it.  I want to add that whatever mechanism you all create
to implement this feature, please make sure it can work in an
untrusted applet.  There are many many applications for applets
that are able to have a constant KeepAlive connection back
to the originating web server, but it would be a disservice if
we are forced to have our typically technophobic users enter
into the frightening world of certificates and keystores.

(Review ID: 102814)
======================================================================

Name: skT45625			Date: 07/27/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

When using a URLConnection object against a web server that sends back
'keep-alive' in the HTTP header for the Connection field, the client closes
the underlying socket 5 seconds after the response has been recieved.

All the objects that were used in the initial request/response are still in
scope (i.e. this is not a side effect due to the GC doing its job).

I changed the Connection field value in the response to 'close' and the
connection was closed immediately (as it should be). However, when I use 'keep-
alive', the connection does stay open for a short period, but is closed 5
seconds after the response has been recieved. As a result, I can't reuse that
connection.

// CODE
	public void run() {
		try {
			URL url = new URL("http://localhost");
			URLConnection connection = null;
			BufferedWriter writer = null;
			BufferedReader reader = null;
			String line = null;

			// LOGIN
			connection = url.openConnection();
			connection.setDoOutput(true);
			connection.setDoInput(true);
			connection.setUseCaches(false);
			connection.setRequestProperty("Content-
Type", "text/xml");

System.out.println("CLASS: " + (connection.getClass()).getName());

			writer = new BufferedWriter(
				new OutputStreamWriter
(connection.getOutputStream()));
			System.out.println("SENDING:\n" + logindoc);
			writer.write(logindoc, 0, logindoc.length());
			writer.close();

System.out.println("CONNECTION: " + connection.getHeaderField("Connection"));
			reader = new BufferedReader(
				new InputStreamReader(connection.getInputStream
()));
			System.out.println("\nRECIEVED:");
			while((line = reader.readLine()) != null) {
				System.out.println(line);
			}
			reader.close();
// Its during the following sleep that the server side gets a null on the
// socket indicating the client is issuing an EOF.
try { sleep(6000); }
catch(InterruptedException e) {}
			// PUBLISH
			connection = url.openConnection();
			connection.setDoOutput(true);
			connection.setDoInput(true);
			connection.setUseCaches(false);
			connection.setRequestProperty("Content-
Type", "text/xml");

			writer = new BufferedWriter(
				new OutputStreamWriter
(connection.getOutputStream()));
			System.out.println("SENDING:\n" + pubdoc);
			writer.write(pubdoc, 0, pubdoc.length());
			writer.close();

			reader = new BufferedReader(
				new InputStreamReader(connection.getInputStream
()));
			System.out.println("\nRECIEVED:");
			while((line = reader.readLine()) != null) {
				System.out.println(line);
			}
			reader.close();
(Review ID: 107635)
======================================================================

Name: nt126004			Date: 11/12/2001


java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

There doesn't seem to be any facility for timing out an HttpURLConnection.  You
should be able to specify the number of milliseconds that you are willing to
wait for the connection to be established, before taking an alternate course of
processing (likely through catching an exception).
(Review ID: 135189)
======================================================================

                                    

Comments
EVALUATION

	The URLConnection api normally abstracts away the socket and raw
HTTP connection and instead models single request/reply transactions.
The only way I can forsee allowing application code to access or
manipulate socket level issues is in the context of allowing a
custom socket factory to be set on a protocol-specific subclass of
URLConnection such as HttpURLConnection. In that case, persistent
HTTP connections, pipelining and the like would only be shared across
HttpURLConnection instances that passed in a common socket factory instance.

	This request will be considered in the broader context of
exposing a socket factory construct.

jeff.nisewanger@Eng 1998-10-30

One possibility is through the use of SocketFactory, like what JSSE did in its HttpURLHandler.

yingxian.wang@eng 2000-02-08
====================================================================

Independent of the outcome of this rfe, the following may be useful.
A system property "http.defaultSocketTimeout" is being defined
for 1.4 which will define a maximum number of milli-seconds to wait
in a blocking read in HTTP connections. A SocketTimeoutException
will be thrown if the timeout is reached.

michael.mcmahon@ireland 2001-02-02
===================================================================



Developers tracking this RFE should check-out 4700777 as tiger (1.5)
has introduced new setReadTimeout and setConnectTimeout methods to
java.net.URLConnection so that applications can specify the read and
connect timeouts.

For 1.4.x the workaround is to use the sun.net.client.defaultReadTimeout
and sun.net.client.defaultConnectTimeout system properties. These
system properties are specific to the Sun provided protocol handlers
and aren't a general/API solution. However they are useful workaround
until tiger is released.
                                     
2004-06-11



Hardware and Software, Engineered to Work Together