users@grizzly.java.net

Re: org.glassfish.grizzly.Buffer.get(i) != org.glassfish.grizzly.Buffer.toByteBuffer().get(i)

From: Евгений Бушуев <yevgen.bushuyev_at_gmail.com>
Date: Fri, 28 Nov 2014 21:18:46 +0200

Hi,

The example is the code you've suggested in "Read doesn't work" thread. In
the DbProtocolFilter.handleRead dbResponseBuffer passed to
processResponse(associatedHttpRequest,
response, dbResponseBuffer) sometimes returns 'wrong' ByteBuffer. I'm not
100% sure, but I think it happens under heavy loads with two http handlers
registered.

Best regards, Eugene.

2014-11-28 20:31 GMT+02:00 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>:

> Hi,
>
> may be I misunderstood your problem.
> Can you pls. give an example where you think it fails. Expected vs.
> reality :)
>
> Thank you.
>
> WBR,
> Alexey.
>
>
> On 28.11.14 02:33, Евгений Бушуев wrote:
>
> Ok, but how then can I check if it was created with an offset and get
> 'proper' byte buffer? All usages I can find in samples just check if it's
> not composite and call toByteBuffer.
>
> I'm getting the 'wrong' byteBuffer from Grizzly Buffer obtained from
> ctx.getMessage() in a filter and have no control upon its creation, I just
> call myConnection.write(new ByteBufferWrapper(requetBytes)) (as you
> suggested here before). But I still want to keep my code using 'pure' nio
> types and thus want to get bytebuffer from grizzly buffer.
>
> Best regards, Eugene.
>
> 2014-11-27 19:01 GMT+02:00 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>:
>
>> Hi,
>>
>> yes, it's normal.
>> Grizzly Buffer may wrap a ByteBuffer with a specific offset or just a
>> part of ByteBuffer (view), which you have to consider.
>> Normally when you do toByteBuffer() - the returned ByteBuffer's position
>> and limit will represent current Grizzly Buffer's view.
>>
>> WBR,
>> Alexey.
>>
>>
>> On 27.11.14 08:12, Евгений Бушуев wrote:
>>
>>> Hi!
>>>
>>> Is it legal for a org.glassfish.grizzly.Buffer
>>> (org.glassfish.grizzly.memory.HeapMemoryManager.TrimmableHeapBuffer#TrimmableHeapBuffer)
>>> to return ByteBuffer from its toByteBuffer method so that ByteBuffer's
>>> content won't be same as in original grizzly.Buffer?
>>>
>>> Can't figure out why this happens, seems to be random. The
>>> grizzly.Buffer instance is not composite.
>>>
>>> Best regards, Eugene.
>>>
>>
>>
>
>