You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Theo Hultberg (JIRA)" <ji...@apache.org> on 2013/10/30 14:23:26 UTC

[jira] [Commented] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver

    [ https://issues.apache.org/jira/browse/CASSANDRA-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809065#comment-13809065 ] 

Theo Hultberg commented on CASSANDRA-6270:
------------------------------------------

In that case Cassandra should fail the request because it uses a CQL syntax that is not supported over that version of the protocol. Cassandra has accepted that the connection will use CQL v3.0.0 and the frame was sent with v1 of the protocol. The right thing to do is to fail the request because it uses features that are not in CQL v3.0.0, but instead it sends a frame back that a v1 driver cannot parse.

Drivers can't tell if the CQL is valid because they don't parse it, they can't tell if the CQL uses features not available in the version of the binary protocol or not. Cassandra has to say that the request is not valid, and it can't send frames back that are not valid in the protocol specified by the driver.

> SERIAL consistency in errors to v1 protocol driver
> --------------------------------------------------
>
>                 Key: CASSANDRA-6270
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6270
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 2.0
>            Reporter: Theo Hultberg
>            Priority: Minor
>
> I'm the author of the Ruby driver for CQL, and I got a bug report about strange errors when running on C* 2.0 and using lightweight transaction queries. The bug report can be found here: https://github.com/iconara/cql-rb/issues/53
> The client sent {{UPDATE table SET val = 42 WHERE row_id = 5 IF val = 41}} and when C* couldn't fulfill SERIAL consistency it sent an error back saying "Operation timed out - received only -1 responses".
> So far so good, but it also set the {{consistency}} field in the error response to 8, corresponding to {{SERIAL}} in v2 of the binary protocol, even if the communication with the client was over v1 of the protocol. Since my driver doesn't yet support v2 it doesn't think that 8 is a valid consistency, and fails to parse the frame.
> Is this the intended behaviour of C*, or an oversight in how that error is formulated? I could easily add {{SERIAL}} and accept it even if the communication is over v1 of the protocol, but the bigger issue is how C* handles drivers that do not speak the latest version of the protocol. People should be able to use a driver that worked correctly with C* X with C* X+1, right?
> Do drivers have to be accepting in what they receive from C* because they might get consistencies, data types, etc. that are from future versions of the protocol, or does C* guarantee that frames will conform to the protocol that the driver says it understands?



--
This message was sent by Atlassian JIRA
(v6.1#6144)