HttpURLConnection.getOutputStream() returns ChunkedOutputStream when setChunkedStreamingMode(4k) is called. But ChunkedOutputStream copies when write(byte[], off, len) is called. When ChunkedOutputStream.write(buf[20MB], off, len) is called, it keeps a copy of 20 MB. Thus, applications run of memory. There is no need to keep 20 MB in buf field since the chunk size 4k. This limits severly some of the JAX-WS applications and forces JAX-WS to do chunking before writing to ChunkedOutputStream. The fact that we are using chunking to avoid buffering doesn't help.
Posted Date : 2007-02-16 22:38:59.0

N/A

This isn't a bug. The way the HttpURLConnection API is defined, we need to buffer the
whole output stream so it can be replayed in some situations.

However, in cases where a very large output is being sent, and the overhead of buffering
is too great, then the application should use streaming mode.

See the apidocs for HttpURLConnection.set{FixedLength,Chunked}StreamingMode()
Posted Date : 2007-02-28 11:39:42.0

See the bug report, it does use setChunkedStreamingMode(4k)

HttpURLConnection.setChunkedStreamingMode(4k)
OutputStream os = HttpURLConnection.getOutputStream()
os.write(buf[20MB], 0, 20MB)
os.write(buf[40MB], 0, 40MB)

In this case, sun.net.www.http.ChunkedOutputStream contains a private field buf with 40MB. There is no need to keep buffer of 40MB. It doesn't keep 60MB and there is no replay of the request in this streaming mode. os.write() method itself should push the data in 4k chunks
Posted Date : 2007-02-28 18:47:56.0

Yes, even though this looks like a strange use case (20MB byte[] call to write), we should support it. Will fix in jdk7 first.
Posted Date : 2007-03-05 14:12:35.0