Hi Tim,
FYI
> it's javadoc issue, we'll add one.
> I'm currently working on extending the
StaticHttpHandler.sendFile(...) method, so it would be possible to pass
CompletionHandler to check the send file status.
Implemented in Grizzly 2.3
http://java.net/jira/browse/GRIZZLY-1265
WBR,
Alexey.
> On 05/16/2012 05:27 PM, Tim Quinn wrote:
>> 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
>>
>