[ https://issues.apache.org/jira/browse/CASSANDRA-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne resolved CASSANDRA-6535. ----------------------------------------- Resolution: Fixed Fix Version/s: 1.2.14 Reviewer: Sylvain Lebresne +1, committed, thanks. > Prepared Statement on Defunct CF Can Impact Cluster Availability > ---------------------------------------------------------------- > > Key: CASSANDRA-6535 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6535 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Cassandra 1.2.12 > CentOS 6.4 > Reporter: Adam Holmberg > Fix For: 1.2.14 > > Attachments: 6535.txt > > > *Synopsis:* misbehaving clients can cause DoS on a cluster with a defunct > prepared statement > *Scenario:* > 1.) Create prepared INSERT statement on existing table X > 2.) Table X is dropped > 3.) Continue using prepared statement from (1) > *Result:* > a.) on coordinator node: COMMIT-LOG-WRITER + MutationStage errors > b.) on other nodes: "UnknownColumnFamilyException reading from socket; > closing" --> leads to thrashing inter-node connections > c.) Other clients of the cluster suffer from I/O timeouts, presumably a > result of (b) > *Other observations:* > * On single-node clusters, clients return from insert without error because > mutation errors are swallowed. > * On multiple-node clusters, clients receive a confounded 'read timeout' > error because the closed internode connections do not propagate the error > back. > * With prepared SELECT statements (as opposed to INSERT described above). A > NullPointerException is caused on the server, and no meaninful error is > returned to the client. > Besides the obvious "don't do that" to the integrator, it would be good if > the cluster could handle this error case more gracefully and avoid undue > impact. -- This message was sent by Atlassian JIRA (v6.1.5#6160)