[
https://issues.apache.org/jira/browse/QPID-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176485#comment-16176485
]
Rob Godfrey commented on QPID-7837:
-----------------------------------
{code}
if (frameParsingError != null)
{
_connectionHandler.handleError(frameParsingError);
_errored = true;
}
}
catch (RuntimeException e)
{
LOGGER.warn("Unexpected exception handling frame", e);
// This exception is unexpected. The up layer should handle error
condition gracefully
_connectionHandler.handleError(this.createError(ConnectionError.CONNECTION_FORCED,
e.toString()));
}
{code}
This is all sorts of horrible (and, yes, I probably wrote it :-) )... but
shouldn't it at least set _errored = true in the catch block? Also in this
case (and in the case of other framing errors) I would think we would want to
put the connection handler into a state where it ignores all input other than
close... since we have been unable to process a frame we shouldn't really
process any frame after it.
> Malformed annotated messages (message format 0) can lead to
> ClassCastException
> -------------------------------------------------------------------------------
>
> Key: QPID-7837
> URL: https://issues.apache.org/jira/browse/QPID-7837
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: qpid-java-broker-7.0.0
> Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> As per this thread, the Broker can fail unexpectedly with illegal input.
> http://qpid.2158936.n2.nabble.com/Malframed-AMQP-packets-are-accepted-tc7664321.html#none
> The implementation should be sufficiently robust to fail the connection, but
> the Broker service should survive.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
