Thank you very much!
Best regards, Eugene.
2014-11-29 0:23 GMT+02:00 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>:
>
> 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 for toByteBuffer statethat:
>
> Converts this <code>Buffer</code>
> to a {_at_link ByteBuffer}.
>
> * If this <code>Buffer</code> is not composite - then returned* {_at_link ByteBuffer}'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_link ByteBuffer} 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 to grizzly.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>:
>
>> 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>:
>>
>>> 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>:
>>>
>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>