cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-6535) Prepared Statement on Defunct CF Can Impact Cluster Availability
Date Thu, 02 Jan 2014 13:18:51 GMT

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

Mime
View raw message