cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10146) Deprecate v1 and v2 protocol in 2.2, drop support in 3.0
Date Fri, 04 Sep 2015 14:59:46 GMT

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

Sylvain Lebresne commented on CASSANDRA-10146:
----------------------------------------------

A few minor remarks (which, outside of the 1st one which is a bug, are mostly suggestions/nits):
* In {{CollectionType}}, what we want is get rid of {{enforceLimit}}, not enforce it unconditionally.
* I think we could explicit both the 2.2 warning and the NEWS messages a bit. Typically, for
the 2.2 warning, I'd got with something like "Detected connection using native protocol version
%d. Both version 1 and 2 of the native protocol are now deprecated and support will be removed
in Cassandra 3.0. You are encouraged to upgrade to a client driver using version 3 of the
native protocol", and some similar instruction on what people have to do in the NEWS file.
* In {{Frame.java}}, can rename {{MODERN_LENGTH}} to {{LENGTH}} and can use it directly in
{{encode}} and {{decode}} rather than assigning it to a {{headerLength}} variable.
* If we introduce {{Server.SUPPORTED_VERSIONS}}, which we'll have to maintain, it makes more
sense to check if the version received is contained in that list in {{Frame.decode()}}. But
truly, I would have simply added {{MIN_SUPPORTED_VERSION}} instead, used that (and {{CURRENT_VERSION}})
for the test and error message during frame decoding. That would avoid mistake like forgetting
to add a new version to {{SUPPORTED_VERSIONS}} (not that it's an error that is likely to stay
unnoticed for long, but the less you have to do ...).


> Deprecate v1 and v2 protocol in 2.2, drop support in 3.0
> --------------------------------------------------------
>
>                 Key: CASSANDRA-10146
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10146
>             Project: Cassandra
>          Issue Type: Task
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Benjamin Lerer
>              Labels: client-impacting, doc-impacting
>             Fix For: 2.2.x, 3.0.0 rc1
>
>
> In 3.0, we would like to use frozen collections in the system keyspaces, and it seems
likely that we will eventually want to use tuples or nested collections as well.  Drivers
that only support protocol versions 1 and 2 will not be able to read these system keyspaces
because they cannot decode those types.
> I think this is a good time to start deprecating and dropping support for old protocol
versions.  The v3 protocol was introduced in 2.1, so if we remove support for v1 and v2 in
3.0, that gives users two major versions to upgrade their drivers.  Fortunately, upgrading
drivers to a version that supports the v3 protocol is generally straightforward.
> The benefits of doing this are:
> * We can use new types in the system keyspaces
> * We can eliminate protocol-version-specific encoding and decoding of collections within
Cassandra
> * Driver maintainers can eventually drop support for old protocol versions once all C*
versions that support them are EOL
> To avoid a hard drop of v1 and v2 support in 3.0, I propose that we also officially deprecate
these in 2.2.  Unfortunately, we don't have protocol-level warnings until v4, so we can't
use that to notify users of the deprecation, but the combination of a NEWS.txt entry, warning
logs, and (potentially) driver-level warnings should suffice.



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

Mime
View raw message