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)
