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)