[
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: (was: 2.0.2)
2.0.3
> 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.3
>
>
> 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.
