cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12838) Extend native protocol flags and add supported versions to the SUPPORTED response
Date Fri, 28 Oct 2016 06:45:58 GMT


Stefania commented on CASSANDRA-12838:

Thank you for the review. I've replaced the {{compareTo}} calls with more descriptive methods,
and I've added a couple of unit tests (the utility method for making a page state is a cut
and paste). It's all in one [commit|],
the 3.X patch applies to trunk without conflicts.

In terms of renaming {{ProtocolVersion}}, I wouldn't mind renaming it if there was an equivalent
name but I couldn't find any. I don't think we should add the protocol type because the class
lives in the native protocol package, so I disregarded something like {{NativeProtocolVersion}}.
I consider the fact that we need to use the java driver in our unit tests a limitation, so
I don't want to pick a not-so-good name because of it, but if someone has a name that it is
truly equivalent to {{ProtocolVersion}}, then I don't mind renaming it.


CI is still pending, there were unrelated problems with the dtests this morning, I've pinged
the TEs and relaunched. 

The pull request for the driver is [here|].
[~aholmber] can we arrange a time slot next week, morning your time, where we can commit this
ticket and simultaneously merge the pull request into cassandra-test, so that we minimize
dtest failures for people, there are about 160 dtests using version 5, and they will fail
without the driver changes.

> Extend native protocol flags and add supported versions to the SUPPORTED response
> ---------------------------------------------------------------------------------
>                 Key: CASSANDRA-12838
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: CQL
>            Reporter: Stefania
>            Assignee: Stefania
>             Fix For: 3.x
> We already use 7 bits for the flags of the QUERY message, and since they are encoded
with a fixed size byte, we may be forced to change the structure of the message soon, and
I'd like to do this in version 5 but without wasting bytes on the wire. Therefore, I propose
to convert fixed flag's bytes to unsigned vints, as defined in CASSANDRA-9499. The only exception
would be the flags in the frame, which should stay as fixed size.
> Up to 7 bits, vints are encoded the same as bytes are, so no immediate change would be
required in the drivers, although they should plan to support vint flags if supporting version
5. Moving forward, when a new flag is required for the QUERY message, and eventually when
other flags reach 8 bits in other messages too, the flag's bitmaps would be automatically
encoded with a size that is big enough to accommodate all flags, but no bigger than required.
We can currently support up to 8 bytes with unsigned vints.
> The downside is that drivers need to implement unsigned vint encoding for version 5,
but this is already required by CASSANDRA-11873, and will most likely be required by CASSANDRA-11622
as well.
> I would also like to add the list of versions to the SUPPORTED message, in order to simplify
the handshake for drivers that prefer to send an OPTION message, rather than rely on receiving
an error for an unsupported version in the STARTUP message. Said error should also contain
the full list of supported versions, not just the min and max, for clarity, and because the
latest version is now a beta version.
> Finally, we currently store versions as integer constants in {{}}, and we
still have a fair bit of hard-coded numbers in the code, especially in tests. I plan to clean
this up by introducing a {{ProtocolVersion}} enum.

This message was sent by Atlassian JIRA

View raw message