[jira] Updated: (DIRMINA-811) Exceptions in MessageDecoder.decode() cause problems for subsequent decode operations.

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRMINA-811:
--------------------------------------

    Fix Version/s: 2.0.2

> Exceptions in MessageDecoder.decode() cause problems for subsequent decode operations.
> --------------------------------------------------------------------------------------
>
>                 Key: DIRMINA-811
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-811
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.1
>         Environment: Windows 7 and jdk1.6.0_18
>            Reporter: Björn Thelberg
>            Priority: Minor
>             Fix For: 2.0.2
>
>
> 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 responses and exceptions and I am in general very pleased with how this works.
> But if an Exception is thrown from the decode()-method the problem begins.
> The Exception is passed on to an ExceptionHandler just as excpected but the DemuxingProtocolDecoder's state.currentDecoder is not cleared so a subsequent decode operation is passed directly to the previously used MessageDecoder's decode()-method without selecting a new decoder, using decodable()-calls. This is of course a problem as the next message could require a different decoder and chances are big that the decoding will throw a new Exception and we can't recover from that state.
> This differs from what happens if you return MessageDecoderResult.NOT_OK from decode() (where the state.currentDecoder is cleared) even though both events are documented as "protocol specification violations".
> In conjunction with this the IoBuffer can be "half read" when the Exception is thrown and must some how be cleared before new messages can be received and decoded.
> One approach to go around this is to do a try-catch in every decode()-method and skip the remaining bytes in the buffer and return NOT_OK in the catch-block.
> Sadly enough you can not BOTH return NOT_OK and re-throw the Exception. So the nice ExceptionHandler-functionality in MINA goes to waste.
> Also it feels wrong  to be forced to do try-catch in every decode()-method for Exceptions that make the current message unreadable, could not the framework handle that and give subsequent messages a chance to be properly decoded?
> (Exceptions during decoding that you ARE prepared for and CAN handle to rescue the current message is a different story, the specific decode()-method can catch those and handle them in a proper way.)
> My humble suggestion is to let the DemuxingProtocolDecoder in it's doDecode() catch Exceptions, reset the current decoder and buffer and re-throw the Exceptions. But I'm no expert of MINA internals.
> I am made aware that the IoBuffer can contain more than one message and that clearing it could loose a valid second message.
> But if the decode()-method chooses not to handle the Exception, my guess is that there is no way of knowing where the first message ends and the second begins outside that MessageDecoder anyway.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.