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
> <mailto: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.
>
>
>