[
https://issues.apache.org/jira/browse/DIRMINA-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018275#comment-13018275
]
Björn Thelberg commented on DIRMINA-811:
----------------------------------------
Oh, sorry! Didn't know about the vote at all! :)
Actually I would prefer re-throwing the same exception, so that the appropriate
exception handler is choosen just like before.
That makes it backwards compatible for those who depend on a special exception
handler being used for a specific exception type
and rely on information in the original exception object.
Also, in my opinion, there is a risk of loosing information if the original
exception is not preserved.
What do you think of that?
Great if you could include this fix!
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
