AW: ByteBuffer Anomaly??

[Steve Ulrich <st...@proemion.com>]

Hi!

Did you made sure, you read previous the message completely from the ByteBuffer? The part you don't read at the *decode* method is passed to the decodable (and decode) method again.
So if a message is 5 bytes and you read up to the 4th byte in you decode-process, than the 5th byte is the first one at the next call of decodable. You just have to do a byteBuffer.get() oder byteBuffer.position(byteBuffer.position+1) at the end of your decode method, to consume that byte.

hth & regards

Steve

> Johny Kadarisman [mailto:jkr888@gmail.com] wrote:
>
> Emannuel,
>
> I think I found the problem. The decodable() methods doesn't receive a
> clean
> bytebuffer (or with a left over unused byte from previous decoder) even
> after I successfully decode the message.
>
> Which module is actually responsible to call compact() method on the
> bytebuffer?
>
>
> On Fri, May 30, 2008 at 9:47 AM, Emmanuel Lecharny
> <el...@apache.org>
> wrote:
>
> > Johny Kadarisman wrote:
> >
> >> I run for standalone, its correct. Any changes from my previous
> code?
> >>
> >>
> >
> > I replaced the debug calls by System.out, removed the response object
> > (didn't had the code for it), used a HashMap to store parameters, and
> that's
> > it.
> >
> > One more point : doing str.getBytes() is not good. Depending on your
> local
> > default String encoding, you may have a totally different result from
> one
> > machine to another one. You should do getBytes( encoding ) where
> encoding is
> > the encoding used for your string. In your case, "UTF-8" should be
> ok.
> >
> >
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >

Re: ByteBuffer Anomaly??

[Emmanuel Lecharny <el...@apache.org>]

Johny Kadarisman wrote:
> Thanks Steve, I finally found the solutions of my problem. I miss understood
> the bytebuffer behaviour.
> I try to mimic the http example, since the protocol i'm working is similar
> to it. But the problem in my case, the session is not terminate on each
> request. So, In certain cases, Mina call decodable methods with bytebuffer
> contained previous request. In the example, It check the http methods using
> absolute methods. Which lead me to the assumption that, buffer will always
> contain a new bytes. Which is wrong. After I change all the buffer related
> access to relative mode. Now, everything working good.
>   
Yeah, this is quite a common error. The fact is that ByteBuffers are 
used as if they contain the data ready to be processed by the user's 
codec. This was somehow leading to mistakes, up to a point we started 
thinking about removing completely the ByteBuffer/IoBuffer class to 
replace it by an InputStream (sort of).

Buffers are generally speaking intended to store temporary data while 
they are copied from one layer to another. We used them with a modified 
semantic ad it was far from perfect. For instance, in order to offer 
extended functionalities like extended buffers ( ByteBuffers which size 
can be increased as we receive new bytes) we had to rewrite a complete 
proxy on top of the NIO byteBuffer. At the end of the day, it 
represented something like 20% of the code base.

2.0 should be much more easier to use.

Thanks !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: ByteBuffer Anomaly??

[Johny Kadarisman <jk...@gmail.com>]

Thanks Steve, I finally found the solutions of my problem. I miss understood
the bytebuffer behaviour.
I try to mimic the http example, since the protocol i'm working is similar
to it. But the problem in my case, the session is not terminate on each
request. So, In certain cases, Mina call decodable methods with bytebuffer
contained previous request. In the example, It check the http methods using
absolute methods. Which lead me to the assumption that, buffer will always
contain a new bytes. Which is wrong. After I change all the buffer related
access to relative mode. Now, everything working good.

Thanks, Rgds,

Johny K.

On Mon, Jun 2, 2008 at 3:29 AM, Steve Ulrich <st...@proemion.com>
wrote:

> Hi!
>
> Did you made sure, you read previous the message completely from the
> ByteBuffer? The part you don't read at the *decode* method is passed to the
> decodable (and decode) method again.
> So if a message is 5 bytes and you read up to the 4th byte in you
> decode-process, than the 5th byte is the first one at the next call of
> decodable. You just have to do a byteBuffer.get() oder
> byteBuffer.position(byteBuffer.position+1) at the end of your decode method,
> to consume that byte.
>
> hth & regards
>
> Steve
>
> > Johny Kadarisman [mailto:jkr888@gmail.com] wrote:
> >
> > Emannuel,
> >
> > I think I found the problem. The decodable() methods doesn't receive a
> > clean
> > bytebuffer (or with a left over unused byte from previous decoder) even
> > after I successfully decode the message.
> >
> > Which module is actually responsible to call compact() method on the
> > bytebuffer?
> >
> >
> > On Fri, May 30, 2008 at 9:47 AM, Emmanuel Lecharny
> > <el...@apache.org>
> > wrote:
> >
> > > Johny Kadarisman wrote:
> > >
> > >> I run for standalone, its correct. Any changes from my previous
> > code?
> > >>
> > >>
> > >
> > > I replaced the debug calls by System.out, removed the response object
> > > (didn't had the code for it), used a HashMap to store parameters, and
> > that's
> > > it.
> > >
> > > One more point : doing str.getBytes() is not good. Depending on your
> > local
> > > default String encoding, you may have a totally different result from
> > one
> > > machine to another one. You should do getBytes( encoding ) where
> > encoding is
> > > the encoding used for your string. In your case, "UTF-8" should be
> > ok.
> > >
> > >
> > >
> > > --
> > > --
> > > cordialement, regards,
> > > Emmanuel Lécharny
> > > www.iktek.com
> > > directory.apache.org
> > >
> > >
> > >
>