cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Petrov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12142) Add "beta" version native protocol flag
Date Wed, 20 Jul 2016 08:13:20 GMT

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

Alex Petrov commented on CASSANDRA-12142:
-----------------------------------------

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)

Mime
View raw message