Vovodroid created CASSANDRA-8945: ------------------------------------ Summary: Error log is written on client malformed request Key: CASSANDRA-8945 URL: https://issues.apache.org/jira/browse/CASSANDRA-8945 Project: Cassandra Issue Type: Improvement Components: Core Environment: 2.1.3 Reporter: Vovodroid Priority: Minor
When client sends wrong or malformed request error log is printed, though it's not Cassandra bug or problem. {code:title=Message.java|borderStyle=solid} @Override public boolean apply(Throwable exception) ....................................... // Anything else is probably a bug in server of client binary protocol handling logger.error(message, exception); ...................................... {code} Assume public Cassandra server (for instance accepting connection from widely distributed application, e.g. mobile). Badly written or hostile applications can flood Cassandra log. I discovered two possible scenarios so far: 1. Connect with telnet to Cassandra and send any string. *exception* is _io.netty.handler.codec.DecoderException_ *cause* is _org.apache.cassandra.transport.ProtocolException_ *message* is _Invalid or unsupported protocol version_ 2. Connect to Cassandra with password authentication with client that doesn't recognize that (sending request as reply to AuthResponse) *exception* is _java.lang.AssertionError_ *cause* is _org.apache.cassandra.exceptions.InvalidRequestException_ *message* is _Protocol error: Unexpected message QUERY, expecting SASL_RESPONSE_ Thus I suggest that way to distinguish between Cassandra originated exception and bad clients should be found not to print log in latter cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)