V2 Binary Protocol Support - Missing consistency levels

[adstage-david]

Getting an error: Unknown consistency index 8.

Looks like this is supposed to correspond to serial?:
https://github.com/datastax/java-driver/blob/2.0/driver-core/src/main/java/com/datastax/driver/core/ConsistencyLevel.java#L30

I'm trying out the new lightweight transactions syntax. Not sure if this is supported/will break other stuff. (UPDATE table SET val = 42 WHERE row_id = 5 IF val = 41)

[iconara]

SERIAL and LOCAL_SERIAL are in v2 of the binary protocol and cql-rb doesn't yet support them. I'll leave this issue open as a feature request (v2 protocol support will be added, but I want to get v1.1.0 with the auto reconnection and peer discovery out first).

If you'd like you could try adding the consistency levels to this line and see what happens:

https://github.com/iconara/cql-rb/blob/master/lib/cql/protocol.rb#L18

I haven't tried it myself but it might be the case that it works even if the connection is not v2.

[adstage-david]

I decided I didn't really want the overhead of the transaction anyway, but I had a feeling there might be more to this error. Didn't realize it was a completely new binary protocol. Does this possibly mean I could be encountering other errors on this connection that are more subtle because I'm communicating to a server that thinks it's talking v2?

[iconara]

No the server shouldn't think it's communicating using v2 of the protocol. What did you do to get the error? It looks to be like the error you got was because the driver couldn't decode the error it got back because referred to a consistency that is not in the spec... I think this is actually a bug, or at least an oversight in Cassandra. If I'm right the error was something on the line "you must specify consistency SERIAL when using IF", but the decoding failed since that error also includes a reference to the consistency, which the deserializer chokes on.

[adstage-david]

I'm not entirely sure where the error originated from in my code. The specs were all running fine, but when I hit the page with a browser it would occasionally error out. I'm using an update call very similar to the one above, in a prepared statement.

Playing with the same CQL in IRB (with prepared statement and without) and I'm not able to reproduce it the error - the lightweight transactions are going through fine and not raising any errors, even when I specify consistency level :one or :quorum.

[iconara]

Weird. Maybe it was some other error, timeout or other unavailability error, and since it contained the SERIAL consistency cql-rb errored out. If it happens again, please record as much as you can.

[adstage-david]

Still not exactly sure what causes this, but it appears to only happen if one of my nodes is down or taking to long to respond. My best guess is in normal cases the returned consistency matches what I was requesting (:quorum) but when one of those nodes is down it reports a different consistency of :serial? Not sure how the binary protocol works underneath.

[adstage-david]

I take that back, restarted with a brand new cluster (3 nodes instead of two for my consistency level of 2), all nodes currently running fine and I'm still getting this. Tried a fork with :serial and :local_serial available and then the message has problems elsewhere:

CQL::QueryError => Operation timed out - received only -1 responses.

This doesn't seem right, but I'm not sure what would cause it.

[iconara]

Good, that error is the real error, the error you got before just masked it (because it was in the decoding on the error that the error you got was raise -- got it?).

That error you got now has a field in the protocol called consistency that is "the consistency level of the query having triggered the error". I throw that away (should probably copy it to the error I raise), but it's still parsed.

I think what happens is that when your query uses IF Cassandra automatically rewrites the consistency to SERIAL and ignores the consistency you sent.

I'll open an issue in Cassandra for this to see if this is really the intended behaviour.

In the meantime you should probably run with your patched version and retry when you get that error (the same you would if you sent a regular query with QUORUM and got a timeout back).

[iconara]

I've opened CASSANDRA-6270, we'll see what they say.

[iconara]

Serial consistency support will come with #74. You'll use it like this:

client.execute('UPDATE x SET y = 1 WHERE z = 2 IF w = 3', consistency: :quorum, serial_consistency: :local_serial)

note that the consistency of the request (:quorum) and the consistency of the paxos round (:local_serial) are two different things. :serial is default, so most of the time you don't need to specify it.