P4
FULL PRODUCT VERSION :
java version " 1.7.0_25 "
Java(TM) SE Runtime Environment (build 1.7.0_25-b17)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
Microsoft Windows [Version 6.0.6002]
A DESCRIPTION OF THE PROBLEM :
Suppose a HTTP client connects to a com.sun.net.httpserver with a GET but does not consume the full response for a large amount of data (e.g. a bigger file).
Then the HTTP handler gets an IOException when writing to the output stream as supplied by HttpExchange.getResponseBody().
The next time the output stream is closed, another IOException is raised by close().
If that exception is consumed, e.g. because the output stream was explicitly closed by the HTTP handler, calling HTTPExchange.close() will no longer close the HTTP connection and the connection with it's large buffer will be left in memory forever.
The HttpConnection instance will be lying around, too, unclosed with the channel still unclosed.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Perform an HTTP GET with a 20m output, have the client close the TCP connection after reading some 100 bytes.
Perform a GC with visualvm, then take a heap dump.
Examine the 20th largest instances.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No HttpConnection and Request.WriteStream instances left.
ACTUAL -
Find HttpConnection and Request.WriteStream instances containing 2m buffers. Connection is still unclosed, channel is not closed, too.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Avoid to close the output stream. Don't use try-with-resources on HttpExchange.getResponseBody. Only close the HttpExchange.
Then the connection will be closed.
Set sun.net.httpserver.maxRspTime=120 or similar to have the connection cleaned up.
java version " 1.7.0_25 "
Java(TM) SE Runtime Environment (build 1.7.0_25-b17)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
Microsoft Windows [Version 6.0.6002]
A DESCRIPTION OF THE PROBLEM :
Suppose a HTTP client connects to a com.sun.net.httpserver with a GET but does not consume the full response for a large amount of data (e.g. a bigger file).
Then the HTTP handler gets an IOException when writing to the output stream as supplied by HttpExchange.getResponseBody().
The next time the output stream is closed, another IOException is raised by close().
If that exception is consumed, e.g. because the output stream was explicitly closed by the HTTP handler, calling HTTPExchange.close() will no longer close the HTTP connection and the connection with it's large buffer will be left in memory forever.
The HttpConnection instance will be lying around, too, unclosed with the channel still unclosed.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Perform an HTTP GET with a 20m output, have the client close the TCP connection after reading some 100 bytes.
Perform a GC with visualvm, then take a heap dump.
Examine the 20th largest instances.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No HttpConnection and Request.WriteStream instances left.
ACTUAL -
Find HttpConnection and Request.WriteStream instances containing 2m buffers. Connection is still unclosed, channel is not closed, too.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Avoid to close the output stream. Don't use try-with-resources on HttpExchange.getResponseBody. Only close the HttpExchange.
Then the connection will be closed.
Set sun.net.httpserver.maxRspTime=120 or similar to have the connection cleaned up.