[jira] [Updated] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver
[
https://issues.apache.org/jira/browse/CASSANDRA-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-6270:
Labels: LWT (was: )
> 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
> Labels: LWT
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver
[
https://issues.apache.org/jira/browse/CASSANDRA-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-6270:
Attachment: 6270.txt
I agree that sending frames that are not valid is a tad anti-social. Attaching
simple patch that throw an InvalidRequestException if the user tries to use CAS
with the protocol v1.
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)
[jira] [Updated] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver
[
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)
[jira] [Updated] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver
[
https://issues.apache.org/jira/browse/CASSANDRA-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-6270:
-
Reviewer: Aleksey Yeschenko
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)
