cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12142) Add "beta" version native protocol flag
Date Wed, 06 Jul 2016 13:59:11 GMT


Sylvain Lebresne commented on CASSANDRA-12142:

This isn't clearly started in the description, but I think we should just use this ticket
to introduce the v5 protocol, setting it in beta for now. That is, I see that ticket as mainly
creating the {{native_protocol_v5.spec}} with support for that beta flag.

As for the flag itself, we probably should add it to each message "flags" byte (2nd byte of
the header) since the protocol version is more associated to messages than connection in practice.
Which also mean I'm not sure we should expose this through the {{SUPPORTED}} message, since
that message itself is conditioned by the protocol version.

In other words, the way I'd implement this is that the server would know which version is
beta and would just reject message from a beta version unless the "I'm ok using a beta version"
flag is set on the message. That way, drivers that want to test if a given version is supported
as stable can just try it (without the beta flag) and will just get an "unsupported" error
if it's not. 

> Add "beta" version native protocol flag
> ---------------------------------------
>                 Key: CASSANDRA-12142
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Tyler Hobbs
>              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

View raw message