FULL PRODUCT VERSION :
build 1.6.0-b105

EXTRA RELEVANT SYSTEM CONFIGURATION :
use with jnlpdownloadservlet on glassfish

A DESCRIPTION OF THE PROBLEM :
when download web start application on http://www.docdoku.com it takes lot of time to download on jre 1.6 whereas it's very fast on 1.5.

The files are pack200 compressed using jdk1.5 we use jnlpdownloadservlet to deliver the application.

On the server side we notice error log (only when client is 1.6):

ClientAbortException: java.io.IOException: Broken pipe
at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:414)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:331)
at org.apache.coyote.tomcat5.OutputBuffer.writeBytes(OutputBuffer.java:442)
at org.apache.coyote.tomcat5.OutputBuffer.write(OutputBuffer.java:429)
at org.apache.coyote.tomcat5.CoyoteOutputStream.write(CoyoteOutputStream.java:106)
at jnlp.sample.servlet.DownloadResponse$FileDownloadResponse.sendRespond(DownloadResponse.java:153)
at jnlp.sample.servlet.JnlpDownloadServlet.handleRequest(JnlpDownloadServlet.java:113)
at jnlp.sample.servlet.JnlpDownloadServlet.doGet(JnlpDownloadServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
try to download the web start application http://www.docdoku.com with 1.5 and 1.6 and then see the difference.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
download should be as fast as with 1.5. Moreover we should not have broken pipe exception on the jnlpdownloadservlet while the server is responding.
ACTUAL -
download takes huge time and error log on server side.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Try to reproduce it with the given scenario, if you want I'm ready to help.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The workaround is to wait a while...
CAP member submit the same concern with more following information:

There is a problem with webstart downloading the jar files when there
is an update. This looks exactly like bug 6522222.

Sometimes failed jar file downloads will give the user an error up front,
however sometimes its effects of it will lay dormant for a while and then
manifest itself as a NoSuchMethodError. If this happens to happen during a
critical phase of our app, terrible things can happen.

Webstart is used to download and start applications. Because of this, it
really has to work 100% of the time.

Our application is really nothing special and our network is fast. It just
seems that if webstart is not in the memory or disk cache, downloads will
fail.

In my custom download servlet I put a 5 second sleep before I sent the jar
file over the network. It looks like I got one ClientAbortException in my
servlet log for every file. It looks like it then tried to download all the
files again, but I don't know why it had to fail 30 times first. Perhaps it
thinks it is making a HEAD request or a last modified check first?

The transactions for the failed downloads are not HEAD requests. As they do
not have the request header of that, nor do they get routed to the doHead()
method of the servlet (they get processed by the doGet() method).
HTTP headers and values:

content-type = application/x-java-archive
accept-encoding = pack200-gzip,gzip
user-agent = JNLP/6.0 javaws/1.6.0_04 (b12) Java/1.6.0_04
ua-java-version = 1.6.0_04
host = frisky.dev.donnell.com:8407
cache-control = no-cache
pragma = no-cache
accept = text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
connection = keep-alive
if-modified-since = Tue, 29 Jan 2008 20:35:23 GMT

The webstart trace logging does not have timestamps or threadIds, so it is
difficult to see for sure what is happening. However, it looks like a bunch
of threads are opened to contact the jar files. Then this happens again.
Maybe if things are working correctly the first group of threads comes back
before the second group starts. However with the 5 second sleep I put in my
servlet before any GET reply, this seems to cause problems.

It seems like the algorithm maybe was supposed to be:
1) Do a HEAD request on all the jar files using the "if-modified-since"
header
2) Then, for each file,
2a) If the HEAD request comes back with a HTTP 200 (OK)
-> Download the jar file
2b) If the HEAD request comes back with a HTTP 304 (NotModified)
-> Skip it

However, the first group are not doing HEAD requests. This doesn't really
cause a problem, except that since the payload is never read, the webserver
registers this as an abort. Also, the second group of threads is not
waiting for the first groups answers. This seems like a bigger deal.

If this is the algorithm, there are some obvious threading issues here. If
the second thread is not going to wait on the first group, then the first
group does not have much value. If the first requests were actually HEAD
requests, they would probably return quicker, but one should not count on
this to occur.

Looking at the clientadminC.jar (just picking a jar file at random), here is
the sequence
1510 (Connect)
1546 (Connect)
1716 - 1777 (Disconnect) Gets response code, but then disconnects. From the
log I get from the servlet, I am guessing it is reading the header, but not
the payload.
1774 - 1719 (Disconnect) This one may have actually download the jar.

-------------------------------------------------------------------------------------

More comments from the CAP member


Now looking at DownloadEngine.java and BasicHttpRequest.java, it seems like
it should be making some HEAD requests. However, my tomcat access log shows
no HEAD requests are ever received. It would be interesting to see what the
values are of isHead in BasicHttpRequest.createURLConnection(). Random
checks of the packets using a network sniffer corroborate this.

My network sniffer sees the GET header in the HTTP packet, so it is either
being set by the BasicHttpRequest or it has a default of "GET".

The only "javaplugin" property I see when I press 's' in the console is
"javaplugin.proxy.config.type". Since "javaplugin.version" does not seem to
be set, Environment.isJavaPlugin() should return false.

The code looks like it should work...

--------------------------------------

BasicHttpRequest.java:74
  public HttpResponse doHeadRequest(URL url) throws IOException {
    // always use GET request for Java Plugin
    return doRequest(url, Environment.isJavaPlugin() ? false : true, null,
null, true);
  }

BasicHttpRequest.java:302
  if (conn instanceof HttpURLConnection) {
    ((HttpURLConnection)conn).setRequestMethod((isHead) ? "HEAD" : "GET");