[jira] [Comment Edited] (CASSANDRA-12142) Add "beta" version native protocol flag

["Alex Petrov (JIRA)" <ji...@apache.org>]

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

Alex Petrov edited comment on CASSANDRA-12142 at 7/20/16 8:13 AM:
------------------------------------------------------------------

I've made a patch that adds the {{USE_BETA}} flag to frame header flags. 

There's sill one open question though, as both ways seem possible, it'd be good to hear your opinion:

Right now, the protocol failures (for example, incorrect version) would result into server responding to client with it's {{CURRENT_VERSION}} of the protocol. 

If the connection is established with an incorrect version (let’s say {{42}}) by the client, should the server still respond with {{42}}? Or should it respond with the {{CURRENT_VERSION}}?

Currently there’s a check for version in decoder that’s used on server (and in SimpleClient), which checks that the version is still the same, although I couldn’t find similar code in Java driver (response would come with different version and will be consumed normally).

The problem on the server side is that version is set for `connection`, not for `channel` and connection is only initialised later, which means that server would respond with {{CURRENT_VERSION}}.

We can (a) set version as channel attribute and set it earlier, or initialise connection earlier, or even do it only for explicit protocol exceptions, or (b) allow client to consume the messages with a different version (as it is now, with an exception of {{SimpleClient}}), but then we might want to document that server might respond this way.

Early version of the Java Driver patch is [here|https://datastax-oss.atlassian.net/browse/JAVA-1248].

|[trunk|https://github.com/ifesdjeen/cassandra/tree/12142-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12142-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12142-trunk-dtest/]|


was (Author: ifesdjeen):
I've made a patch that adds the {{USE_BETA}} flag to frame header flags. 

There's sill one open question though, as both ways seem possible, it'd be good to hear your opinion:

Right now, the protocol failures (for example, incorrect version) would result into server responding to client
with it's {{CURRENT_VERSION}} of the protocol. 

If the connection is established with an incorrect version (let’s say {{42}}) by the client, should the server
still respond with {{42}}? Or should it respond with the {{CURRENT_VERSION}}?

Currently there’s a check for version in decoder that’s used on server (and in SimpleClient), which checks
that the version is still the same, although I couldn’t find similar code in Java driver (response would come
with different version and will be consumed normally).

The problem on the server side is that version is set for `connection`, not for `channel` and connection is
only initialised later, which means that server would respond with {{CURRENT_VERSION}}.

We can (a) set version as channel attribute and set it earlier, or initialise connection earlier, or even do it
only for explicit protocol exceptions, or (b) allow client to consume the messages with a different version
(as it is now, with an exception of {{SimpleClient}}), but then we might want to document that server
might respond this way.

Early version of the Java Driver patch is [here|https://datastax-oss.atlassian.net/browse/JAVA-1248].

I left protocol changes in v4 document to make the review easier. When the patch is reviewed, I'll 
create a v5 document and clean it up. I also took a chance to go through the code and switch to constants
instead of integers for protocol versions. It's easier to track protocol-related things if they're
searchable. 

|[trunk|https://github.com/ifesdjeen/cassandra/tree/12142-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12142-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12142-trunk-dtest/]|

> Add "beta" version native protocol flag
> ---------------------------------------
>
>                 Key: CASSANDRA-12142
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12142
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: CQL
>            Reporter: Tyler Hobbs
>            Assignee: Alex Petrov
>              Labels: protocolv5
>
> As discussed in CASSANDRA-10786, we'd like to add a new flag to the native protocol to allow drivers to connect using a "beta" native protocol version.  This would be used for native protocol versions that are still in development and may not have all of the final features.  Without the "beta" flag, drivers will be prevented from using the protocol version.
> This is primarily useful for driver authors to start work against a new protocol version when the work on that spans multiple releases.  Users would not generally be expected to utilize this flag, although it could potentially be used to offer early feedback on new protocol features.
> It seems like the {{STARTUP}} message body is the best place for the new beta flag.  We may also considering adding protocol information to the {{SUPPORTED}} message as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)