Hi.
I am seeing odd behavior with the GlassFish Java Web Start support during the download of the orb-iiop.jar file from the server to the client. (This is in the trunk, GF 4.0.)
When I take Java Web Start itself out of the picture, and just use curl to try to download the file, I get this result. Note that I have specified the URL which is handled by a custom Grizzly adapter.
tjquinn-mac:archive tjquinn$ curl -o thejar.jar
http://localhost:8080/___JWSappclient/___system/s1as/glassfish/modules/orb-iiop.jar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
93 88013 93 81920 0 0 2677 0 0:00:32 0:00:30 0:00:02 0
curl: (18) transfer closed with 6093 bytes remaining to read
This URL causes the server to download a signed copy of the orb-iiop.jar file.
When I copy the signed JAR to the domain's docroot and try to curl it from there it works fine. Because that bypasses the custom Grizzly adapter, it's possible that the custom Grizzly adapter is not correctly driving the Grizzly API.
The Grizzly adapter that is responding to the long URL has, in part, the code below. The variable fileToSend is a File which correctly points to the signed JAR to be downloaded, and gResp is a GrizzlyResponse.
/*
* Delegate to the Grizzly implementation.
*/
StaticHttpHandler.sendFile(gResp, fileToSend);
final int status = gResp.getStatus();
if (status != HttpServletResponse.SC_OK) {
logger.fine(logPrefix() + "Could not serve content for "
+ relativeURIString + " - status = " + status);
} else {
logger.fine(logPrefix() + "Served static content for " + gReq.getMethod()
+ ":" + sc.toString());
}
finishResponse(gResp, status);
} catch (Exception e) {
// gResp.getResponse().setErrorException(e);
finishErrorResponse(gResp, HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
logger.log(Level.SEVERE, logPrefix() + relativeURIString, e);
}
I've discovered that when this code hits the red line it causes an IllegalStateException pasted below.
What's weird is that the exception happens for every file, even ones that are downloaded correctly.
Also what's weird is that when I step through this code with the debugger the file that fails downloads successfully.
So, I suspect that (1) I am doing something wrong in preparing the response and (2) my doing something wrong causes a timing issue that affects this particular file, and by debugging the code I disrupt the timing issue so that even the problematic download succeeds in that case.
Have I violated anything in the Grizzly programming model that causes this exception? Have there been recent changes in Grizzly that might have exposed what I'm doing wrong?
Thanks.
- Tim