mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DIRMINA-811) Exceptions in MessageDecoder.decode() cause problems for subsequent decode operations.
Date Fri, 10 Dec 2010 18:47:17 GMT

     [ 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)

> 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
> 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

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

View raw message