JDK-6886436 : Lightwight HTTP Container (com.sun.* package) is unstable
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6u16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2009-09-29
  • Updated: 2013-09-12
  • Resolved: 2009-10-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u32Fixed 7 b75Fixed
Related Reports
Relates :  
JDK-6888555 - Http server needs to log certain error situations
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.
07-10-2009