On 28.11.14 13:46, Евгений Бушуев wrote:
> Yes, the limit and position of the buffers are really different. Like this:
> dbResponseBuffer.limit() = 396
> dbResponseBuffer.position() = 0
> dbResponseBuffer.toByteBuffer().limit() = 676
> dbResponseBuffer.toByteBuffer().position() = 280
Right, it's acceptable.
> so I've been reading bytes out of position-limit range. But, the docs fortoByteBufferstatethat:
> Converts this<code>Buffer</code> to a {_at_linkByteBuffer}.
> * If this<code>Buffer</code> is not composite - then returned
> * {_at_linkByteBuffer}'s content is a shared subsequence of this buffer's
> * content,...
Correct the content is shared, but position/limit values are not, or at
least not guaranteed.
> and docs for grizzly buffer say that
> JDK {_at_linkByteBuffer} was taken as base for Grizzly <tt>Buffer</tt>
> so get(i) should return correct value regardless of limit/position or throw exception.
Sure, you can read, but it doesn't guarantee that the result of this
ByteBuffer get(i) is equal to Buffer.get(i);
> With this in mind, could you please suggest a way to obtain nio.ByteBuffer from grizzly.Buffer so that nio.ByteByffer.get(i) will always be equal togrizzly.Buffer.get(i) ?
Even though I think it's a bit redundant requirement, IMO this should work:
ByteBuffer byteBuf = grizzlyBuffer.toByteBuffer(0,
grizzlyBuffer.capacity()).slice();
WBR,
Alexey.
> Best regards, Eugene.
>
> 2014-11-28 22:03 GMT+02:00 Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> <mailto:oleksiy.stashok_at_oracle.com>>:
>
> Let's doublecheck one thing, we're talking about ByteBuffer's
> content within its [/*position*/; /*limit*/) boundaries, right?
> You don't have to check ByteBuffer's content outside of these
> boundaries.
> So when you do:
>
> ByteBuffer byteBuf = grizzlyBuffer.toByteBuffer();
>
> The content of Grizzly Buffer is located within ByteBuffer's
> [/*position*/; /*limit*/). The returned ByteBuffer's /*position*/
> might be > 0 and its /*limit*/ != /*capacity*/.
> To make sure the byteBuf content is correct or incorrect do this:
>
> ByteBuffer byteBuf = grizzlyBuffer.toByteBuffer().slice();
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> On 28.11.14 11:46, Евгений Бушуев wrote:
>> Grizzly Buffer's content seems to be correct. It's binary data
>> (mongo's bson, http://bsonspec.org/) so it's difficult to make
>> sure if it's correct looking at it in debugger. But at least
>> documents' boundaries in the beginning of the doc are correct.
>> The returned ByteBuffer content resembles mix of responses from
>> sibling handler.
>>
>> Best regards, Eugene.
>>
>> 2014-11-28 21:29 GMT+02:00 Oleksiy Stashok
>> <oleksiy.stashok_at_oracle.com <mailto:oleksiy.stashok_at_oracle.com>>:
>>
>> Hmm,
>>
>> when it happens can you pls. check if Grizzly Buffer's
>> content is correct and the problem is only seen in the
>> ByteBuffer content?
>> Is the ByteBuffer content completely wrong or it's only
>> ByteBuffer's position/limit problem?
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>> On 28.11.14 11:18, Евгений Бушуев wrote:
>>> 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
>>> <mailto: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
>>>> <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.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>