[ 
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)

Reply via email to