[
https://issues.apache.org/jira/browse/CASSGO-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18040667#comment-18040667
]
João Reis commented on CASSGO-97:
---------------------------------
{quote}I'm trying to understand which protocol errors it is referring to.
{quote}
Protocol error is a specific error response type defined by the spec that can
be used anytime a client or server receives data in a format that is not
compliant with spec. It can be thrown post handshake (usually due to some kind
of bug somewhere or if one side is expecting compression/tls and the other
isn't) but it's mostly used in the protocol version negotiation part of the
handshake (the "unsupported protocol version" or "version is beta but beta flag
wasn't set" errors that you've seen).
{quote}This comment makes me think that the *stream id of 0* is guaranteed to
be returned if the driver tries to send a request with an unsupported proto
version... Is the case of *unsupported protocol version (X)* response
documented anywhere? I can't really find it...
{quote}
Since a protocol error means something went wrong related to the protocol
itself it's possible that the server doesn't even know which stream id to use
in the response (maybe it wasn't even able to decode the frames properly). In
these scenarios the server can just return stream id 0 as a default, a protocol
error should always lead to closing the connection anyway so regardless of what
stream id is used the end result should be the cancellation (or retry on the
next connection) of all pending requests.
But this isn't consistent, sometimes a protocol error response does come with a
valid stream id.
>From that comment it looks like gocql doesn't use stream id 0 when sending
>requests and in that case any response with stream id 0 can probably be safely
>assumed to be a protocol error (but you can just decode the response body
>anyway). Not all drivers do this though. I guess that code is needed because
>otherwise the driver will try to lookup the context for stream id 0 which will
>never exist but we could also just handle protocol errors always in this part
>of the code before even looking up stream ids if we want to, otherwise we'll
>end up with 2 different places to handle protocol errors (one in the part of
>the code that processes responses after the response has been matched with the
>request and another for the special case of stream id = 0 which seems to be
>the current case).
{quote}If this is the way other drivers handle protocol negotiation, then I'm
+1 on this.
{quote}
At least the java driver does it. The C# driver also parses the string but it's
something that should be changed as well, downgrading 1 by 1 is the only
consistent way of doing it that doesn't depend on error string parsing.
> Protocol version negotiation doesn't work if server replies with stream id
> different than 0
> -------------------------------------------------------------------------------------------
>
> Key: CASSGO-97
> URL: https://issues.apache.org/jira/browse/CASSGO-97
> Project: Apache Cassandra Go driver
> Issue Type: Bug
> Components: Core
> Reporter: João Reis
> Priority: Normal
> Fix For: 2.x
>
>
> If the server's ProtocolError response comes with stream id 0 then [this
> code|https://github.com/apache/cassandra-gocql-driver/blob/0326fae3617dd19b901f2e9a97479c04fc11e05a/conn.go#L685-L700]
> will create the protocol error object.
> If the response comes with a positive stream id then [this
> code|https://github.com/apache/cassandra-gocql-driver/blob/0326fae3617dd19b901f2e9a97479c04fc11e05a/conn.go#L1314-L1330]
> will create the protocol error object. This latter way of creating the error
> makes [the regex check not
> work|https://github.com/apache/cassandra-gocql-driver/blob/0326fae3617dd19b901f2e9a97479c04fc11e05a/control.go#L210-L245].
> This was found when trying to connect to
> [ZDM-Proxy|https://github.com/datastax/zdm-proxy/] but connecting to a C*
> 3.11.x cluster works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
