dev@grizzly.java.net

Re: ProtocolParser Issue with Reallocation of ByteBuffer

From: Parker Lord <plord_at_seecontrol.com>
Date: Wed, 13 May 2009 13:09:42 -0700 (PDT)

I have tried the last two suggestions, things work much better.
I changed setContinousExection to 'false' and now set 'hasMoreBytesToParse'
to false as it should be.
I pulled out the latest trunk code and am using that with my testcase.
I take it this trunk code will be released as release 1.9.16 in the newar
future?


I have attached my latest sample code that I am using.

I have still seen on occaision, the 'Buffer is full' exception and will keep
an eye on it.

http://www.nabble.com/file/p23529060/Sample.zip Sample.zip


Hi,

>
> The client code was included in the original post, as well as
> attached as a
> zip file in my last update. The client class is called
> ClientSampleMain. It
> just creates a large String message and sends it via TCP.
>
> As to your points below:
>
> 1) I looked at the javadoc again, and its actually: get(byte[] dst,
> int
> offset, int length) so I did have it incorrect. I have updated my
> example
> and re-attached the zip file. This is not the issue, though its wrong
> anyway. I did it like this to verify that the correct bytes from the
> buffer
> are copied.
Ok.

>
>
> 2) Thats one of my problems, if I set it to false, the parser never
> gets
> re-invoked, even though i tell it i need more bytes. The only way I
> can get
> it to re-invoked is to set it to true. I showed why in the included
> code
> from the framework.
hasMoreBytesToParse should be really false.
The issue you see should be fixed on trunk.
Can you pls. try it out?

Thanks.

WBR,
Alexey.

-- 
View this message in context: http://www.nabble.com/ProtocolParser-Issue-with-Reallocation-of-ByteBuffer-tp23416360p23529060.html
Sent from the Grizzly - Development mailing list archive at Nabble.com.