Did anyone have some input on this one?

In short my problem is that on exceptions in a MessageDecoder's decode()-method 
the DemuxingProtocolDecoder does not reset the state.currentDecoder so 
following decoding operations (following messages) go directly to the same 
decoder (does not try other decoders decodable()-method) and therefore usually 
crash again. Se previous messages below for details.

/Björn

-----Ursprungligt meddelande-----
Från: Björn Thelberg [mailto:[email protected]] 
Skickat: den 2 november 2010 18:23
Till: [email protected]
Ämne: SV: Question about DemuxingProtocolCodecFactory and MessageDecoder

Thanks for your reply Emmanuel!
 
How do you mean I should "clean up" the session?
 
I have tried to do the following in my decoder:
try {
//...decoding stuff
} catch (Exception e) {
   in.skip(in.remaining());
   throw e;
}
It should fix the problem with remaining bytes in the buffer but I am still 
stuck with the same decoders decodable()-call in the next response i receive 
(no matter type).
 
I see that the DemuxingProtocolDecoder does the following magic in doDecode():
//...
else if (result == MessageDecoder.NOT_OK) {
            state.currentDecoder = null;
//...
But exceptions are not catched in the doDecode().
 
Would it not make sense if the DemuxingProtocolDecoder did the same on 
exceptions and re-threw them?
Just like NOT_OK results Exceptions are also documented as ""protocol 
specification violation" in the MessageDecoder.decode().
Or is there a use case that I am missing where you do want to return to the 
same decoder after an exception?
 
Even if there is a way to reset the current decoder from within a catch-block 
in a decoder's decodable() that I am not aware of I think it would be nice if 
you didn't have to do try-catch in every decoder implementation but rather let 
the framework take care of that. Do you agree?

/Björn Thelberg


-----Ursprungligt meddelande-----
Från: Emmanuel Lecharny [mailto:[email protected]] 
Skickat: den 29 oktober 2010 12:17
Till: [email protected]
Ämne: Re: Question about DemuxingProtocolCodecFactory and MessageDecoder

On 10/28/10 1:34 PM, Björn Thelberg wrote:
> Hello
Hi,

> I am writing a client implementation for a binary protocol using a 
> ProtocolCodecFilter with a DemuxingProtocolCodecFactory and a list of 
> MessageDecoder's in the same way as the Mina SumUp example.
> I also use a DemuxingIoHandler to handle the responses and I am in general 
> very pleased with how this works.
Fine !
> My question is as follows.
> If I for some reason get an exception in one of my MessageDecoder's 
> decode()-method due to a broken response of some sort, what is supposed to 
> happen next?
The ExceptionCaught event is generated, and you can handle it in your 
handler.
> What happens for me is that the exception is passed to my ExceptionHandler 
> and decoding of this message quits. Fine so far.
Ok, works as expected :)
> But the subsequent decode operation (following a new request) is immediately 
> passed on to the same MessageDecoder instance's decode().
Makes sense. I guess it's on the same session.
> This is of course a problem if the next response is of another type because 
> the chain of MessageDecoder's decodable() are never called.
> Also it sometimes seems as if remaining bytes in the IoBuffer from decoding#1 
> (that threw Exception) are still in the buffer in decoding#2 and my decoding 
> crashes (again).
You may have to clenup the session when you get the exception in your 
decoder, otherwise the cumulative buffer will keep the faulty data.
> I interpret the Javadoc for MessageDecoder.decode() as if throwing exception 
> would mean roughly the same thing as returning MessageDecoderResult.NOT_OK.
> Do they not both indicate a "protocol specification violation"?
> It seems as throwing exception in the decode()-method acts more like 
> returning MessageDecoderResult.NEED_DATA.
>
> I quess I can solve this problem by catching all exceptions in decode() and 
> returning MessageDecoderResult.NOT_OK but then my ExceptionHandler is never 
> called.
You can also try to catch the exception, clean the session, and rethrow 
the initial exception ?

Let me know if it works.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Reply via email to