Hi,
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..
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?
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
>
>