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)
