United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6886436 Lightwight HTTP Container (com.sun.* package) is unstable
JDK-6886436 : Lightwight HTTP Container (com.sun.* package) is unstable

Details
Type:
Bug
Submit Date:
2009-09-29
Status:
Resolved
Updated Date:
2013-09-12
Project Name:
JDK
Resolved Date:
2009-10-24
Component:
core-libs
OS:
windows_xp
Sub-Component:
java.net
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
6u16
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
JSR311 (JAX-RS) 1.0 RI "Jersey"

A DESCRIPTION OF THE PROBLEM :
This is an umbrella bug report for a bug in a private com.sun.* class, the lightweight HTTP server.

The JAX-RS team at Sun Microsystems, namely Paul Sandoz et al., detected several instabilities in this class when using it to implement the JAX-RS (JSR311) reference implementation "Jersey" (http://jersey.dev.java.net). Those instabilities lead to the fact that the project is not using this class anymore but ask people to instead use Grizzly. This obviously is not a permanent solution.

This bug report will serve as an umbrella to collect more information about the unstabilities so it will be possible to fix them in a future release.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The actual problems and the steps to reproduce have to get documented in future.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Jersey should run on the lightweight HTTP server (private part of the JDK) without hanging or crashing.
ACTUAL -
Jersey is hanging after few requests when using the lightweight HTTP server, but is working great with GlassFish.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
There is no error message, it just hangs.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Will get provided at a later time.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Not using the lightweight HTTP server but using Grizzly.

                                    

Comments
EVALUATION

There are two problems being fixed here:

1) On the http server, if the calling code calls HttpExchange.sendResponseHeaders (204, 0);
the intention is to send a 204 - no content response and an empty response body. However, this call actually sends a chunked-encoded empty response body. A strict interpretation of the RFC shows that this is not correct. The response must terminate immediately after the headers and an empty chunked encoded reponse is therefore not allowed. 

The change is to silently convert the the second parameter to a -1, which means a normal empty response body is sent. This occurrence is logged as a warning in case the behavior is unexpected (though it would be a protocol error to send anything else)

2) The HttpURLConnection client when receiving an erroneous response such as the above, misinterprets the chunked encoded response as belonging to the response from the following request (if there is one) on the same connection. The bug is that the client ends up hanging if the application tries to read from the InputStream for this response.

The fix is to detect the problem and throw an Exception.
                                     
2009-10-07



Hardware and Software, Engineered to Work Together