Current http keep-alive implementation requires user code to clean up pending data before it can be reused. it is too much burden on programmers.

Also see #5039967


  xxxxx@xxxxx   2004-05-11

Cut & paste from email discussions about the root cause for 5039967:

Zhengyu Gu wrote: 

"When plugin download jars, it wraps input stream with JarInputStream, even plugin iterators all jar etnries and reads all entry content, it seems that input stream is still not clean. The solution is to empty the input stream  if iterating jar entries.

I realized that your fix was not enough for plugin, I was hoping that networking code could provide simple call to cleanup the channel. For example, if user code call InputStream.close() && keep-alive is on, then close() call should put into pool, and when the connection is retrieved from the pool, cleanup code will be executed to clean up the pending data and connection become resuable."
Posted Date : 2005-08-09 10:10:11.0

N/A

yingxian wang wrote:

"So this bug is really different from the one that Neal @ NSA reported.

InputStream.close() will only try to reuse the connection if all response body has arrived. Otherwise, we wouldn't try to reuse the connection. This is definitely something that we can look into to improve in a future release."

Not clear whether this is a plugin or java.net bug. Check 4814794
Will try to fix in mustang
  xxxxx@xxxxx   2005-06-15 15:44:56 GMT
Posted Date : 2005-06-15 15:44:56.0

Implemented an async cleanup of unread data from the underlying socket. This is configurable through the network properties http.KeepAlive.remainingData and http.KeepAlive.queuedConnections in net.properties.
Posted Date : 2005-09-12 15:37:55.0

How can the other bug 4814794
 which is older and was in the top 25 be marked a 
DUP of this NEWER bug?  

So this bug is no longer in the top 25?  How does that 
make sense?

So if this was top 25 and over a year old, does that 
mean that this new one will not get fixed ever?

Well,  glad to see that the votes are back and this is in the top 25 again.  I guess that means it will get fixed in 1.4.2_x any day now.

No really, it will right?  ;)

Please Sun, fix it asap - cktemper pointed out the (probable) solution 6 months ago (see 4814794)

No progress on this?

How about an update.   This bug is a KILLER for those that need to deploy for developement, demonstration purposes on a non-server os where Keep Alives are required.

For those of use trying to keep java in our stack against the tide of .net cool-aid drivers, this makes us look stupid.

This is also killing the deployment of a new application here which relies on HTTP requests from Applets. WIth this bug we are stuck because after some number of requests the browser "freezes" (too many connections open).

Good job getting this fixed for 5.0.... oh wait, never mind.

Does anyone know if this is fixed in 1.5 or not?

When 4814794 was closed, I entered 4985672, which was promptly closed as "not reproducible in 1.5".  

As I noted in 4814794, this should be a very simple bug to fix!

In the 1.5.0 plugin, keep-alive seems to work in  HttpURLConnection. So I think the bug reported in 4814794,  4985672, 4731837 etc is really fixed. Those reports noted that keep-alive did not work at all in plugin 1.4.x.  I see now that this bug (5045306) is more limited problem.

As with CTemper's comment, we have found that the keep alive ( our main issue) is now working correctly, checking the code, you can see the changes made.  Maybe SUN should comment on this for those tracking this bug as a replacement for the original bug?

Is there ANY process to handle issues at SUN, or is this public log stuff just a sham.

Is Http keep-alive (HttpURLConnection) fixed in 1.4.2_06 as well as 5.0? Anyone know why 1.4.2_06 is the plug-in of choice on java.com and not 5.0 yet??? 

So, is there in 1.5 a way to set  the keepAliveTimeout for an HttpUrlConnection? If I