cassandra-commits mailing list archives

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

             Summary: SERIAL consistency in errors to v1 protocol driver
                 Key: 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:

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