CumulativeProtocolDecoder records the previous position of Bytebuffer

[immars <im...@gmail.com>]

Hello,
I implemented CumulativeProtocolDecoder.doDecode() in my subclass of
CumulativeProtocolDecoder.
In my doDecode(), the most straight-forward way I could figure out of
decoding data is reading fields(Integers, Bytes, Booleans, etc.) of my POJO
step by step following the protocol, until the work is done or an
java.nio.BufferUnderflowException is thrown, which means data not sufficient
for decoding. In the later case, I reset the ByteBuffer to the previous
position before invocation of doDecode().

So I keep thinking that this exception handling aspect should be done by a
super class of many real-protocol concerned decoders, maybe the
CumulativeProtocolDecoder itself.

Here's a example patch to describe my idea:

http://www.nabble.com/file/p12938622/CPD.patch CPD.patch 

Thanks.
-- 
View this message in context: http://www.nabble.com/CumulativeProtocolDecoder-records-the-previous-position-of-Bytebuffer-tf4533829s16868.html#a12938622
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: CumulativeProtocolDecoder records the previous position of Bytebuffer

[immars <im...@gmail.com>]

Hello Lee,
Thank you very much for pointing out my immature consideration on
performance issue. In fact, my situation is that the cpu load of the
application server is constantly below 10%, and the network communication
mainly involves large amount of small messages in the size of less than 512
bytes. So I did not put many consideration on execution efficiency of java
code itself. On the other hand, there is a bunch of legacy code dealing with
object serialization & deserialization based on the java stream I/O
interface, so the easiest way utilizing nio is applying an adapter from
ByteBuffer to Stream I/O, and passing control through exceptions(in fact,
only a small portion of messages would cause an exception).

However, you are right. It's agly and inefficient putting exceptions on the
main control flow. As now I think the best thing todo is to reconsider my
protocol to see if there is any graceful solution.

Thank you very much again.


Trustin Lee wrote:
> 
> Thank you so much for your suggestion.  However, wouldn't it be very
> inefficient if you rely on exceptions?
> 
> 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/CumulativeProtocolDecoder-records-the-previous-position-of-Bytebuffer-tf4533829s16868.html#a12940587
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: CumulativeProtocolDecoder records the previous position of Bytebuffer

[Trustin Lee <tr...@gmail.com>]

On 9/28/07, immars <im...@gmail.com> wrote:
>
> Hello,
> I implemented CumulativeProtocolDecoder.doDecode() in my subclass of
> CumulativeProtocolDecoder.
> In my doDecode(), the most straight-forward way I could figure out of
> decoding data is reading fields(Integers, Bytes, Booleans, etc.) of my POJO
> step by step following the protocol, until the work is done or an
> java.nio.BufferUnderflowException is thrown, which means data not sufficient
> for decoding. In the later case, I reset the ByteBuffer to the previous
> position before invocation of doDecode().
>
> So I keep thinking that this exception handling aspect should be done by a
> super class of many real-protocol concerned decoders, maybe the
> CumulativeProtocolDecoder itself.
>
> Here's a example patch to describe my idea:
>
> http://www.nabble.com/file/p12938622/CPD.patch CPD.patch

Thank you so much for your suggestion.  However, wouldn't it be very
inefficient if you rely on exceptions?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6