Hi Tim,
see comments inline...
On 05/16/2012 06:35 PM, Tim Quinn wrote:
>
> On May 16, 2012, at 11:23 AM, Oleksiy Stashok wrote:
>
>> 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?
Could be, if we modify output stream from several threads - it may
corrupt output.
> 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.
Hmm, response.finish() might cause the thread racing problem.
>
> Does that make sense?
Yep.
Thanks.
WBR,
alexey.
>
> - 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
>>>
>>
>