cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Theo Hultberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver
Date Wed, 30 Oct 2013 13:23:26 GMT


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:
>             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
> 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,
> 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

View raw message