[CASSANDRA-13221] Connection reset handling not working in case of protocol errors

• Type: Bug
• Status: Open
• Priority: Low
• Resolution: Unresolved
• Component/s: Legacy/CQL
• Severity: Low
• Assignee: Unassigned
• Reporter: Stefan Podkowinski
• Created: 15/Feb/17 11:12
• Updated: 16/Apr/19 09:30

Description

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. 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).

Issue Links

• is broken by: CASSANDRA-6236 Update native protocol server to Netty 4
• Is contained by: CASSANDRA-13126 native transport protocol corruption when using SSL