users@grizzly.java.net

Re: Weird issue with HTTP download sample.

From: Daniel Feist <dfeist_at_gmail.com>
Date: Wed, 7 Jan 2015 19:25:09 -0300

Do you have the JIRA # and/or commit reference so I can take a look
and see what the fix was?

Thanks!

On Wed, Jan 7, 2015 at 6:18 PM, Oleksiy Stashok
<oleksiy.stashok_at_oracle.com> wrote:
> Hi,
>
>
> On 07.01.15 04:17, Daniel Feist wrote:
>>
>> This is using org.glassfish.grizzly.samples.http.download.Server along
>> with the Client in same maven module of course. I tested with the
>> latest version in 2.3.x branch. See my second email for more info on
>> what I think is going wrong..
>
> Fixed, nice catch!
>
>> We are currently not using the HttpServer API (no real reason, just
>> didn't really need it), and thats why we are using the approach in
>> this example that leverages a CompletionHandler. Does whats behind
>> Response.getOutputStream() use the same approach, or an alternative?
>
> Well, HttpServer API is similar to Servlet API, it might be easier to use
> it, but there is nothing wrong with your approach.
> And yes, HttpServer API uses the FilterChain similar to http-sample and the
> one you use.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>>
>> thanks,
>> Dan
>>
>> On Tue, Jan 6, 2015 at 11:14 PM, Oleksiy Stashok
>> <oleksiy.stashok_at_oracle.com> wrote:
>>>
>>> Hi Dan,
>>>
>>> On 06.01.15 17:47, Daniel Feist wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've found what I think is something wierd going on with the http
>>>> download example included in the source tree. If you run it with a
>>>> payload larger than chunk size of 1KB then and compare the source file
>>>> (read by Server), and the target file (saved to disk by the Client)
>>>> they are not the same. The file recieved has some content but then is
>>>> nearly all 0's. I've tried this with a number of different payload
>>>> sizes and see rougly the same. I'm still looking into the root
>>>> cause, I'll let you know what I find, but it would be interesting to
>>>> see if anyone else has seen this before or has any thoughts on where
>>>> to look.
>>>
>>> which exactly sample did you try?
>>>
>>>> Is this the recommended approach for sending chunked responses with
>>>> Grizzly? Or rather should org.glassfish.grizzly.http.io.OutputBuffer
>>>> be used somehow?
>>>
>>> If you use HttpServer API along with Response.getOutputStream() - it
>>> should
>>> take care of the chunking. If the response is smaller than output buffer
>>> size - it'll be sent using Content-Length, if the response is larger or
>>> outputStream.flush() is explicitly called - the chinking encoding will be
>>> used.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>> thanks,
>>>> Dan
>>>
>>>
>