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


Mime
View raw message