You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefan Podkowinski (JIRA)" <ji...@apache.org> on 2017/02/15 11:13:41 UTC
[jira] [Created] (CASSANDRA-13221) Connection reset handling not
working in case of protocol errors
Stefan Podkowinski created CASSANDRA-13221:
----------------------------------------------
Summary: Connection reset handling not working in case of protocol errors
Key: CASSANDRA-13221
URL: https://issues.apache.org/jira/browse/CASSANDRA-13221
Project: Cassandra
Issue Type: Bug
Components: CQL
Reporter: Stefan Podkowinski
Priority: Minor
Exceptions during native transport message handling can occur at any time either in the netty stack or within our own frame decoding code. The later will raise a custom ProtocolException that is supposed to be returned to the client. This is done by implementing {{exceptionCaught}} in the inbound dispatch handler. As only protocol errors should be send to the client, we check the exception type there, see [Message.java|https://github.com/apache/cassandra/blob/0811824abbf46182005c5c54cee7b08243f2057a/src/java/org/apache/cassandra/transport/Message.java#L565]. However, starting with netty 4, our {{ProtocolException}} will always be wrapped in a netty {{DecoderException}} and the current netty channel will not get actually closed as intended.
As discussed in CASSANDRA-13126, any DecoderExceptions will likely turn out unrecoverable for the connection, so it's probably a good idea to close the channel when that happens as well and not only in case of ProtocolErrors. However, if you do this the {{MessagePayloadTest.testMessagePayloadVersion3}} unit test breaks and I haven't been able to figure out why by briefly debugging it.
If closing the channel on DecoderException doesn't work for some reason, we should at least close it on ProtocolException as intended, which can be done by checking against the ErrorMessage, ({{errorMessage.error instanceof ProtocolException}}).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)