On May 16, 2012, at 11:23 AM, Oleksiy Stashok wrote:
> 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.
I see.
Do you think that accounts for the file download problem?
I was thinking that perhaps the exception handler in the adapter was giving Grizzly mixed signals by trying to complete the response (again) to report an error that had not really happened. But I assume that, like before, Grizzly would reject any attempt to affect the response at that point.
Yet when I removed the code that tries to get the status and the code that invokes finishResponse (which just sets the status and then invokes GrizzlyResponse.finish) the problematic download seems to work fine.
Does that make sense?
- Tim
>
> 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
>>
>