cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Haslem (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver
Date Wed, 30 Oct 2013 15:07:28 GMT

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

David Haslem commented on CASSANDRA-6270:
-----------------------------------------

I originally reported the bug on the Ruby project, just thought it might be useful to clarify
a bit:

I could _sometimes_ successfully use lightweight transactions successfully over the v1 binary
protocol the ruby driver is using (specifying a consistency of :quorum on writes), but sometimes
it would throw this error. 

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

Mime
View raw message