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 Mon, 31 Oct 2016 03:43:58 GMT


Stefania commented on CASSANDRA-12838:

Thank you, I'll ping you on Monday morning to arrange a time.

> 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
>              Labels: client-impacting
>             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