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] [Updated] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver
Date Wed, 30 Oct 2013 15:35:52 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-6270:
----------------------------------------

    Fix Version/s: 2.0.3

> 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
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 2.0.3
>
>         Attachments: 6270.txt
>
>
> 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)

Mime
View raw message