@@ -275,8 +275,8 @@ public class WebServerFilter extends BaseFilter {
final Buffer buffer = memoryManager.allocate(1024);
// prepare byte[] for InputStream.read(...)
- final byte[] bufferByteArray = buffer.toByteBuffer().array();
- final int offset = buffer.toByteBuffer().arrayOffset();
+ final byte[] bufferByteArray = buffer.array();
+ final int offset = buffer.arrayOffset();
final int length = buffer.remaining();
The problem with the original code was that we didn't consider buffer.toByteBuffer().position();
Anyway the new code is simpler and takes care of that underneath.
Please note, that this sample won't work with memory managers, that allocate direct buffers, which don't have byte[] underneath.
WBR,
Alexey.
On 07.01.15 14:25, Daniel Feist wrote:
> 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
>>>>