The description is a little bit sketchy. The obvious questions are
1. what does the comments in the sample code imply:
"/ THE REPLY -- probably will not get here, not important for test"
does it mean that the response will never arrive and in that case inputstream will block at reading. How are you supposed to reuse this blocked connection then?
2. // Retrieve object reply
result = in.readObject();
We have no idea what kind of response the server will send. will the above read in all the response? if it doesn't and then it closes the inputstream, we can only do our best to clean the stream up in order to reuse it (keep it alive). but if not all data is read and some data is not available yet. then we can't really clean up the socket channel without blocking, so we would close the connection instead of reusing it.
I tested with b49. This is potential a showstoper.
Run an applet with multiple jars, when caching is enabled and cache is clean, downloading each jar will prompt a client authentication dialog box.
Wehn caching is disabled, still prompt two client authentication dialog boxes.
Ok. there should 2 two separate issues, and the showstopper should apply to the second issue.
1. Current implementation of keep-alive require user code to clean up the pending data in the connection channel before the connection can return to reuse pool. java.net should at least provide an explicit way to make a connection resuable, instead of asking user code to do so.
2. By reading through jar input stream till JarInputStream.nextEntry() == null does not clean up the channel. In other word, plugin has to do further clean up during download/cache jar file. Combine with newly filed #5045269 to cause this showstopper.
Filed #5045306 to track #1. Change Synopsis to reflect plugin issue.
There are two more issues that comes up in the test case:
1. When the application encounters a 404 response, it will ignore the IOException and then does a retry. In this case, the underlying tcp connection won't be reused (kept-alive) because the response body is still there to be consumed, so the socket channel is not clean and ready to be reused. What the application needs to do is to call httpurlconnection.getErrorStream() after catching the IOException and read the response body then close the stream.
However, this won't help existing applications. So to address this problem, we (Java Networking) will introduce a workaround this problem by buffering the response body (up to a certain amount and within a time limit) if the response is >=400, thus freeing up the underlying socket connection for reuse. See details in the ccc request with the same bug number.
2. Another problem found in debugging the test case is related to zero length response body. When no response body is present, there is logic in HttpURLConnection to create an EmptyInputStream and put the underlying socket connection into the keep-alive cache to be reused. However, under some circumstances (when content-length was not explicitly set to 0 and ProgressMonitor is turned on) we could wrap a MeteredStream around a BufferedInputStream, which wrapped around a socketinputstream. When the inputstream is to be garbage collected, MeteredStream.finalize method will actually close the underlying socket. This could happen while the underlying socket connection is being reused. The fix is not to wrap a MeteredStream if there is no response body.
In summary, we (Java Networking) will fix these two problems in Tiger-rc.