[jira] Closed: (DIRMINA-436) DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when NOT_OK is returned.
[
https://issues.apache.org/jira/browse/DIRMINA-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-436.
-
> DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when
> NOT_OK is returned.
> --
>
> Key: DIRMINA-436
> URL: https://issues.apache.org/jira/browse/DIRMINA-436
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5,
> 1.1.2
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 1.0.6, 1.1.3
>
>
> On 9/8/07, Igor Grigoryev wrote:
> >
> > I'm wondering why not set currentDecoder = null before throwing exceptions
> > here (see below)
> > ...
> > if( result == MessageDecoder.OK )
> > {
> > currentDecoder = null;
> > return true;
> > }
> > else if( result == MessageDecoder.NEED_DATA )
> > {
> > return false;
> > }
> > else if( result == MessageDecoder.NOT_OK )
> > {
> > //^^^
> > //I mean here first of all
> > throw new ProtocolDecoderException( "Message decoder
> > returned NOT_OK." );
> > }
> > else
> > {
> > //^^^
> > //And here possibly
> > throw new IllegalStateException( "Unexpected decode result
> > (see your decode()): " + result );
> > }
> >
> >
> >
> > Without this it's not possible to recover codec state after unexpected
> > message being received.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: MessageDecoderResult.NEED_DATA in MessageDecoder#decode( )
Hi Trustin Thanks for the info. I found out yesterday just what you've told me now in org.apache.mina.filter.codec.CumulativeProtocolDecoder#decode( ). Thanks for the confirmation. There is a bug in the http server codec example. If it receives more than one http message in a single tcp transmission it does wrongly assumes that a single http message arrived in "HttpRequestDecoder#messageComplete( ): boolean". It shouldn't test if the last bytes are 0x0D 0x0A 0x0D 0x0A, because the buffer could contain: [First Message correctly terminated (0x0D 0x0A 0x0D 0x0A) + Second Incomplete Message (not 0x0D 0x0A 0x0D 0x0A terminated)]. Bogdan On Jan 21, 2008 10:12 AM, Trustin Lee <[EMAIL PROTECTED]> wrote: > Hi Bogdan, > > On Jan 18, 2008 8:06 PM, Bogdan Ciprian Pistol <[EMAIL PROTECTED]> wrote: > > Hello, > > > > Suppose that in a decode(IoSession session, IoBuffer in, > > ProtocolDecoderOutput out) call the IoBuffer is read and some objects > > are written to the ProtocolDecoderOutput. Suppose that the IoBuffer > > contains some more data, but not enough for creating another object > > (to write to the ProtocolDecoderOutput), so I return > > MessageDecoderResult.NEED_DATA. > > You are just safe to return MessageDecoderResult.OK after decoding > only one message. decode() will be invoked again and again until you > return NEED_DATA. > > > What will the IoBuffer contain when more data is available ? > > The old not enough remaining data + the new available data ? > > Yes. You can get the IoBuffer with non-zero position. > > HTH, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 >
Re: MessageDecoderResult.NEED_DATA in MessageDecoder#decode( )
Hi Bogdan, On Jan 18, 2008 8:06 PM, Bogdan Ciprian Pistol <[EMAIL PROTECTED]> wrote: > Hello, > > Suppose that in a decode(IoSession session, IoBuffer in, > ProtocolDecoderOutput out) call the IoBuffer is read and some objects > are written to the ProtocolDecoderOutput. Suppose that the IoBuffer > contains some more data, but not enough for creating another object > (to write to the ProtocolDecoderOutput), so I return > MessageDecoderResult.NEED_DATA. You are just safe to return MessageDecoderResult.OK after decoding only one message. decode() will be invoked again and again until you return NEED_DATA. > What will the IoBuffer contain when more data is available ? > The old not enough remaining data + the new available data ? Yes. You can get the IoBuffer with non-zero position. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
MessageDecoderResult.NEED_DATA in MessageDecoder#decode( )
Hello, Suppose that in a decode(IoSession session, IoBuffer in, ProtocolDecoderOutput out) call the IoBuffer is read and some objects are written to the ProtocolDecoderOutput. Suppose that the IoBuffer contains some more data, but not enough for creating another object (to write to the ProtocolDecoderOutput), so I return MessageDecoderResult.NEED_DATA. What will the IoBuffer contain when more data is available ? The old not enough remaining data + the new available data ? Thanks, Bogdan
Re: MessageDecoder or CumulativeProtocolDecoder
On 10/22/07, mat <[EMAIL PROTECTED]> wrote: > Is there any performance tradeoff by using MessageDecoder instead of > CumulativeProtocolDecoder? There's small additional overhead determining a proper MessageDecoder; DemuxingProtocolCodecFactory iterates all registered MessageDecoders to call decodable(). However, I don't think it's a big overhead because most messages can be determined from its first few bytes. Once a proper MessageDecoder is chosen, there's no overhead. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
MessageDecoder or CumulativeProtocolDecoder
Is there any performance tradeoff by using MessageDecoder instead of CumulativeProtocolDecoder?
[jira] Resolved: (DIRMINA-436) DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when NOT_OK is returned.
[
https://issues.apache.org/jira/browse/DIRMINA-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee resolved DIRMINA-436.
-
Resolution: Fixed
'currentDecoder = null;' has been added as you suggested. Thank you!
> DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when
> NOT_OK is returned.
> --
>
> Key: DIRMINA-436
> URL: https://issues.apache.org/jira/browse/DIRMINA-436
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5,
> 1.1.2
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 1.0.6, 1.1.3
>
>
> On 9/8/07, Igor Grigoryev <[EMAIL PROTECTED]> wrote:
> >
> > I'm wondering why not set currentDecoder = null before throwing exceptions
> > here (see below)
> > ...
> > if( result == MessageDecoder.OK )
> > {
> > currentDecoder = null;
> > return true;
> > }
> > else if( result == MessageDecoder.NEED_DATA )
> > {
> > return false;
> > }
> > else if( result == MessageDecoder.NOT_OK )
> > {
> > //^^^
> > //I mean here first of all
> > throw new ProtocolDecoderException( "Message decoder
> > returned NOT_OK." );
> > }
> > else
> > {
> > //^^^
> > //And here possibly
> > throw new IllegalStateException( "Unexpected decode result
> > (see your decode()): " + result );
> > }
> >
> >
> >
> > Without this it's not possible to recover codec state after unexpected
> > message being received.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-436) DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when NOT_OK is returned.
DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when
NOT_OK is returned.
--
Key: DIRMINA-436
URL: https://issues.apache.org/jira/browse/DIRMINA-436
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.2, 1.0.5, 1.1.1, 1.0.4, 1.1.0, 1.0.3, 1.0.2, 1.0.1,
1.0.0
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 1.0.6, 1.1.3
On 9/8/07, Igor Grigoryev <[EMAIL PROTECTED]> wrote:
>
> I'm wondering why not set currentDecoder = null before throwing exceptions
> here (see below)
> ...
> if( result == MessageDecoder.OK )
> {
> currentDecoder = null;
> return true;
> }
> else if( result == MessageDecoder.NEED_DATA )
> {
> return false;
> }
> else if( result == MessageDecoder.NOT_OK )
> {
> //^^^
> //I mean here first of all
> throw new ProtocolDecoderException( "Message decoder
> returned NOT_OK." );
> }
> else
> {
> //^^^
> //And here possibly
> throw new IllegalStateException( "Unexpected decode result
> (see your decode()): " + result );
> }
>
>
>
> Without this it's not possible to recover codec state after unexpected
> message being received.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: MessageDecoder, decodable and the ByteBuffer
On 6/20/07, James Apfel <[EMAIL PROTECTED]> wrote: Hi Trustin, the bug was on my side. I was accidently reading too many bytes from the ByteBuffer (the message and parts of the next message). Remember: always slice and set the limit! Good to hear that you fixed a bug. Please come again to us whenever you suspect a bug. Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: MessageDecoder, decodable and the ByteBuffer
Hi Trustin, the bug was on my side. I was accidently reading too many bytes from the ByteBuffer (the message and parts of the next message). Remember: always slice and set the limit! James On 6/19/07, Trustin Lee <[EMAIL PROTECTED]> wrote: Hi James, On 6/18/07, James Apfel <[EMAIL PROTECTED]> wrote: > I have a protocol with multiple MessageDecoders and the decoders have > no state. The decodable method is purely used to figure out if the > message is decodable and the actual work is done in decode. The > documentation does not mention if I have to reset the ByteBuffer in > the decodable method after I'm done with it. MINA should reset the position for you. If it doesn't, it's a bug and please let us know with an reproduceable example. > I believe I have to as I'm seeing some very weird behavior if I don't. > An another question that comes up is if the decoders share the same > ByteBuffer instance or rather if MINA takes care of resetting the > ByteBuffer positions before passing it to the next MessageDecoder? The decoders share the ByteBuffer instance, but the position is always readjusted to make sure the side effect (i.e. unexpected behavior) of a certain message decoder. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: MessageDecoder, decodable and the ByteBuffer
Hi James, On 6/18/07, James Apfel <[EMAIL PROTECTED]> wrote: I have a protocol with multiple MessageDecoders and the decoders have no state. The decodable method is purely used to figure out if the message is decodable and the actual work is done in decode. The documentation does not mention if I have to reset the ByteBuffer in the decodable method after I'm done with it. MINA should reset the position for you. If it doesn't, it's a bug and please let us know with an reproduceable example. I believe I have to as I'm seeing some very weird behavior if I don't. An another question that comes up is if the decoders share the same ByteBuffer instance or rather if MINA takes care of resetting the ByteBuffer positions before passing it to the next MessageDecoder? The decoders share the ByteBuffer instance, but the position is always readjusted to make sure the side effect (i.e. unexpected behavior) of a certain message decoder. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
MessageDecoder, decodable and the ByteBuffer
Hi, I have a protocol with multiple MessageDecoders and the decoders have no state. The decodable method is purely used to figure out if the message is decodable and the actual work is done in decode. The documentation does not mention if I have to reset the ByteBuffer in the decodable method after I'm done with it. I believe I have to as I'm seeing some very weird behavior if I don't. An another question that comes up is if the decoders share the same ByteBuffer instance or rather if MINA takes care of resetting the ByteBuffer positions before passing it to the next MessageDecoder? Thanks James
Re: MessageDecoder
On 4/16/07, mat <[EMAIL PROTECTED]> wrote: Thanks. My question is if it happens, will mina close the session? No, it won't. MINA closes the connection only when IOException is raised during I/O. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: MessageDecoder
Thanks. My question is if it happens, will mina close the session? 2007/4/12, Trustin Lee <[EMAIL PROTECTED]>: On 4/12/07, mat <[EMAIL PROTECTED]> wrote: > Hi, > > If something wrong in the MessageDecoder decodeBody(unexpected exception > happened with no handling by programmer), what will mina do? Automatically > close the session? MINA will wrap the exception with ProtocolDecoderException, and throw it. If the exception is already a ProtocolDecoderException so it doesn't need to be wrapped with ProtocolDecoderException, it will be thrown as is. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: MessageDecoder
On 4/12/07, mat <[EMAIL PROTECTED]> wrote: Hi, If something wrong in the MessageDecoder decodeBody(unexpected exception happened with no handling by programmer), what will mina do? Automatically close the session? MINA will wrap the exception with ProtocolDecoderException, and throw it. If the exception is already a ProtocolDecoderException so it doesn't need to be wrapped with ProtocolDecoderException, it will be thrown as is. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
MessageDecoder
Hi, If something wrong in the MessageDecoder decodeBody(unexpected exception happened with no handling by programmer), what will mina do? Automatically close the session? Thanks.
Re: A question about implementing MessageDecoder
On 3/21/07, Rodrigo Madera <[EMAIL PROTECTED]> wrote: Trustin, Now that you mention it, how does MINA decide _when_ to call decodable()? For example, on the HTTP codec example, I see that you actually try to see the tail of the buffer as it was passed to the decodable() function. So decodable() will be called when a line end is encountered? (don't think so =o) 1. decodable() is invoked for all registered MessageDecoders. 2. If one of them returns OK, decode() of the MessageDecoder is invoked until it returns OK. If NOT_OK is returned, an exception is raised. If NEED_DATA is returned, decode() is invoked again later when more data is received. 3. Go to 1. Simple, right? :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: A question about implementing MessageDecoder
Trustin, Now that you mention it, how does MINA decide _when_ to call decodable()? For example, on the HTTP codec example, I see that you actually try to see the tail of the buffer as it was passed to the decodable() function. So decodable() will be called when a line end is encountered? (don't think so =o) Please clarify. Thanks, Rodrigo On 3/21/07, Coding Horse <[EMAIL PROTECTED]> wrote: Once understood, this design is really a beauty to me! Thx to mina again! Trustin Lee wrote: > > Hi, > > On 3/21/07, Coding Horse <[EMAIL PROTECTED]> wrote: >> >> Hi, Trustin, >> >> I really appreciate your wonderful explanation! Could you also shed some >> light on this case when you have time: >> >> When decodable() is called there are 3.5 complete packets of MyPacket, my >> decode() implementation will take out each complete MyPacket and leave >> the >> remaining untouched to wait for more data. In my previous post I said I >> just took out exact one MyPacket and return OK - I didn't care how many >> MyPacket are inside current buffer as long as it contains at least one >> complete MyPacket. It seems to work for me because I found inside >> decodable() the buffer position was adjusted automatically by one >> MyPacket >> after I "get" one MyPacket out in decode(). I just want to know if this >> is >> the recommended way to achieve what I expected. > > Yes, it's the recommended way. Please decode one message at once in > decode() implementation. MINA will call decodable() and decode() > again if there's more to decode. > > HTH, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > > -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9586609 Sent from the mina dev mailing list archive at Nabble.com.
Re: A question about implementing MessageDecoder
Once understood, this design is really a beauty to me! Thx to mina again! Trustin Lee wrote: > > Hi, > > On 3/21/07, Coding Horse <[EMAIL PROTECTED]> wrote: >> >> Hi, Trustin, >> >> I really appreciate your wonderful explanation! Could you also shed some >> light on this case when you have time: >> >> When decodable() is called there are 3.5 complete packets of MyPacket, my >> decode() implementation will take out each complete MyPacket and leave >> the >> remaining untouched to wait for more data. In my previous post I said I >> just took out exact one MyPacket and return OK - I didn't care how many >> MyPacket are inside current buffer as long as it contains at least one >> complete MyPacket. It seems to work for me because I found inside >> decodable() the buffer position was adjusted automatically by one >> MyPacket >> after I "get" one MyPacket out in decode(). I just want to know if this >> is >> the recommended way to achieve what I expected. > > Yes, it's the recommended way. Please decode one message at once in > decode() implementation. MINA will call decodable() and decode() > again if there's more to decode. > > HTH, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > > -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9586609 Sent from the mina dev mailing list archive at Nabble.com.
Re: A question about implementing MessageDecoder
Hi, On 3/21/07, Coding Horse <[EMAIL PROTECTED]> wrote: Hi, Trustin, I really appreciate your wonderful explanation! Could you also shed some light on this case when you have time: When decodable() is called there are 3.5 complete packets of MyPacket, my decode() implementation will take out each complete MyPacket and leave the remaining untouched to wait for more data. In my previous post I said I just took out exact one MyPacket and return OK - I didn't care how many MyPacket are inside current buffer as long as it contains at least one complete MyPacket. It seems to work for me because I found inside decodable() the buffer position was adjusted automatically by one MyPacket after I "get" one MyPacket out in decode(). I just want to know if this is the recommended way to achieve what I expected. Yes, it's the recommended way. Please decode one message at once in decode() implementation. MINA will call decodable() and decode() again if there's more to decode. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: A question about implementing MessageDecoder
On 3/20/07, mat <[EMAIL PROTECTED]> wrote: Sorry about the mistake I made. But somehow decodable is not very neccessary. I can do everything in decode. If no enough packets, i just return NULL and return MessageDecoderResult.NEED_DATA. I guess position reverting back happenshere. Correct me if i am wrong. Thanks. Well, what decodable() is supposed to do is to determine if this MessageDecoder can decode the incoming data or not. Therefore, I think this separation is useful. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: A question about implementing MessageDecoder
Hi, Trustin, I really appreciate your wonderful explanation! Could you also shed some light on this case when you have time: When decodable() is called there are 3.5 complete packets of MyPacket, my decode() implementation will take out each complete MyPacket and leave the remaining untouched to wait for more data. In my previous post I said I just took out exact one MyPacket and return OK - I didn't care how many MyPacket are inside current buffer as long as it contains at least one complete MyPacket. It seems to work for me because I found inside decodable() the buffer position was adjusted automatically by one MyPacket after I "get" one MyPacket out in decode(). I just want to know if this is the recommended way to achieve what I expected. Thanks again! Trustin Lee wrote: > > On 3/19/07, mat <[EMAIL PROTECTED]> wrote: >> I followed the Sumup Server example. In decodable, normally check the >> body >> len. you don't have to care about the position since in decodable get() >> method is to get the length of the body. The rest of bytebuffer is saved >> in >> the instance of the AbstractMessageDecoder. One session is one instance >> of >> the AbstractMessageDecoder if you follow the Sumup Server approach. > > The buffer position is always reverted back after decodable() is > invoked, but decode() should revert the buffer position by itself. It > is because decodable() is for peeking incoming data to choose an > appropriate decoder, and decode() is for actual decoding. If you want > to wait until the whole message is read into the buffer in decode() > implementation, you'd better not to modify the buffer position until > then. > > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > > -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9584258 Sent from the mina dev mailing list archive at Nabble.com.
Re: A question about implementing MessageDecoder
Sorry about the mistake I made. But somehow decodable is not very neccessary. I can do everything in decode. If no enough packets, i just return NULL and return MessageDecoderResult.NEED_DATA. I guess position reverting back happenshere. Correct me if i am wrong. Thanks. 2007/3/20, Trustin Lee <[EMAIL PROTECTED]>: On 3/19/07, mat <[EMAIL PROTECTED]> wrote: > I followed the Sumup Server example. In decodable, normally check the body > len. you don't have to care about the position since in decodable get() > method is to get the length of the body. The rest of bytebuffer is saved in > the instance of the AbstractMessageDecoder. One session is one instance of > the AbstractMessageDecoder if you follow the Sumup Server approach. The buffer position is always reverted back after decodable() is invoked, but decode() should revert the buffer position by itself. It is because decodable() is for peeking incoming data to choose an appropriate decoder, and decode() is for actual decoding. If you want to wait until the whole message is read into the buffer in decode() implementation, you'd better not to modify the buffer position until then. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: A question about implementing MessageDecoder
On 3/19/07, mat <[EMAIL PROTECTED]> wrote: I followed the Sumup Server example. In decodable, normally check the body len. you don't have to care about the position since in decodable get() method is to get the length of the body. The rest of bytebuffer is saved in the instance of the AbstractMessageDecoder. One session is one instance of the AbstractMessageDecoder if you follow the Sumup Server approach. The buffer position is always reverted back after decodable() is invoked, but decode() should revert the buffer position by itself. It is because decodable() is for peeking incoming data to choose an appropriate decoder, and decode() is for actual decoding. If you want to wait until the whole message is read into the buffer in decode() implementation, you'd better not to modify the buffer position until then. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: A question about implementing MessageDecoder
I followed the Sumup Server example. In decodable, normally check the body len. you don't have to care about the position since in decodable get() method is to get the length of the body. The rest of bytebuffer is saved in the instance of the AbstractMessageDecoder. One session is one instance of the AbstractMessageDecoder if you follow the Sumup Server approach. 2007/3/19, Coding Horse <[EMAIL PROTECTED]>: I'm trying to figure out the relationship between decodable() and decode(). By trying and testing I got to the following conclusion but not sure it's correct or not. Please confirm/correct me. Thx! Say my decodable() implementation guarantees that the current buffer contains at least 1 complete MyPacket(but could be more). Since a call of method decodable() guarantees there is at least one complete MyPacket inside buffer "in". I handle this very packet and simply return MessageDecoderResult.OK. in my decode(). I don't have to worry about the remaining stuff in current buffer "in" - mina is so great that it will continue to call decodable() automatically to handle the exact same current buffer "in". The recycle continues until nothing is left in this buffer "in". I guess only after that the buffer starts receiving new data from external world. Coding Horse wrote: > > Hi, > > In my decodable() and decode() methods I use relative get of ByteBuffer to > check data ready or not and return MessageDecoderResult.NEED_DATA when it > is not ready. > > My question: > Should I care about the buffer's position/limit etc. before returning > MessageDecoderResult.NEED_DATA? My "get" changed the buffer's position, > right? > > thx a lot! > -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9540526 Sent from the mina dev mailing list archive at Nabble.com.
Re: A question about implementing MessageDecoder
I'm trying to figure out the relationship between decodable() and decode(). By trying and testing I got to the following conclusion but not sure it's correct or not. Please confirm/correct me. Thx! Say my decodable() implementation guarantees that the current buffer contains at least 1 complete MyPacket(but could be more). Since a call of method decodable() guarantees there is at least one complete MyPacket inside buffer "in". I handle this very packet and simply return MessageDecoderResult.OK. in my decode(). I don't have to worry about the remaining stuff in current buffer "in" - mina is so great that it will continue to call decodable() automatically to handle the exact same current buffer "in". The recycle continues until nothing is left in this buffer "in". I guess only after that the buffer starts receiving new data from external world. Coding Horse wrote: > > Hi, > > In my decodable() and decode() methods I use relative get of ByteBuffer to > check data ready or not and return MessageDecoderResult.NEED_DATA when it > is not ready. > > My question: > Should I care about the buffer's position/limit etc. before returning > MessageDecoderResult.NEED_DATA? My "get" changed the buffer's position, > right? > > thx a lot! > -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9540526 Sent from the mina dev mailing list archive at Nabble.com.
A question about implementing MessageDecoder
Hi, In my decodable() and decode() methods I use relative get of ByteBuffer to check data ready or not and return MessageDecoderResult.NEED_DATA when it is not ready. My question: Should I care about the buffer's position/limit etc. before returning MessageDecoderResult.NEED_DATA? My "get" changed the buffer's position, right? thx a lot! -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9539844 Sent from the mina dev mailing list archive at Nabble.com.
Re: How to unit test MessageDecoder and MessageEncoder
Hi Wolverine, On 12/23/06, wolverine my <[EMAIL PROTECTED]> wrote: Hi! I have written my own MessageDecoder and MessageEncoder. Is it possible to unit test these two classes before the server and client areready? Well, it really doesn't have any differences from unit-testing usual java objects. You could create some mock objects and use them as parameters for each call (e.g. decode()), and check the result (the content of ProtocolDecoderOutput or return value). HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
How to unit test MessageDecoder and MessageEncoder
Hi! I have written my own MessageDecoder and MessageEncoder. Is it possible to unit test these two classes before the server and client areready? If yes, please give me some hints of how to unit test these codec classes. Thank you!
