Hi Tim,
it's javadoc issue, we'll add one.
When you call StaticHttpHandler.sendFile(...) - you actually delegate
request/response processing to Grizzly, it may happen asynchronously...
once File is sent Grizzly will release all the associated resources.
So the rule is "don't touch Request/Response after you called
StaticHttpHandler.sendFile()" :))
I'm currently working on extending the StaticHttpHandler.sendFile(...)
method, so it would be possible to pass CompletionHandler to check the
send file status.
Thanks.
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
>