You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Björn Thelberg (JIRA)" <ji...@apache.org> on 2010/11/19 14:28:15 UTC
[jira] Created: (DIRMINA-811) Exceptions in MessageDecoder.decode()
cause problems for subsequent decode operations.
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
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.
[jira] [Resolved] (DIRMINA-811) Exceptions in
MessageDecoder.decode() cause problems for subsequent decode operations.
Posted by "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 resolved DIRMINA-811.
---------------------------------------
Resolution: Fixed
Assignee: Emmanuel Lecharny
Fixed with http://svn.apache.org/viewvc?rev=1091209&view=rev
> 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
> Assignee: Emmanuel Lecharny
> 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
[jira] [Commented] (DIRMINA-811) Exceptions in
MessageDecoder.decode() cause problems for subsequent decode operations.
Posted by "Björn Thelberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018250#comment-13018250 ]
Björn Thelberg commented on DIRMINA-811:
----------------------------------------
We have been using the following fix for the DemuxingProtocolDecoder for some months of heavy testing now and it has worked fine.
We are no longer stuck in the same decoder after an exception and the exception handling works fine.
DemuxingProtocolDecoder:175
// --- Start of fix for DIRMINA-811 ---
MessageDecoderResult result;
try {
result = state.currentDecoder.decode(session, in, out);
} catch (Exception e) {
state.currentDecoder = null;
throw e;
}
// --- End of fix for DIRMINA-811 ---
> 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
[jira] Updated: (DIRMINA-811) Exceptions in MessageDecoder.decode()
cause problems for subsequent decode operations.
Posted by "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.
[jira] [Commented] (DIRMINA-811) Exceptions in
MessageDecoder.decode() cause problems for subsequent decode operations.
Posted by "Björn Thelberg (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (DIRMINA-811) Exceptions in MessageDecoder.decode()
cause problems for subsequent decode operations.
Posted by "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: (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.
[jira] [Commented] (DIRMINA-811) Exceptions in
MessageDecoder.decode() cause problems for subsequent decode operations.
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018289#comment-13018289 ]
Emmanuel Lecharny commented on DIRMINA-811:
-------------------------------------------
Sure, I'll keep the original exception then.
> 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
[jira] [Commented] (DIRMINA-811) Exceptions in
MessageDecoder.decode() cause problems for subsequent decode operations.
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018263#comment-13018263 ]
Emmanuel Lecharny commented on DIRMINA-811:
-------------------------------------------
Damn it... Just when the vote for MINA-2.0.3 has been launched :)
I have added the suggested patch (slightly modified) :
try {
MessageDecoderResult result = state.currentDecoder.decode(session, in,
out);
...
} catch (Exception e) {
state.currentDecoder = null;
throw new IllegalStateException(
"Unexpected decode result (see your decode()): "
+ e.getMessage() );
}
Can you tell me if the IllegalStateException is ok ?
I may stop the vote, and integrate this patch (plus another one), and restart a vote asap (ie, in the next couple of days.
Thanks *a lot* for the contribution !
> 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