question

This error is hard to track down but in my experience, it's usually caused by a message overflow.

A message frame encoded in CQL native protocol (version 4) looks something like this:

      0         8        16        24        32         40
      +---------+---------+---------+---------+---------+
      | version |  flags  |      stream       | opcode  |
      +---------+---------+---------+---------+---------+
      |                length                 |
      +---------+---------+---------+---------+
      |                                       |
      .            ...  body ...              .
      .                                       .
      .                                       .
      +----------------------------------------

(Source: CQL binary protocol specification version 4)

From the diagram above, the message frame is composed of (a) a header, and (b) the message body. The frame header contains metadata information about the message which includes:

• version indicating frame is a request or response encoded for the protocol version
• flags such as compression information or warnings from the server
• stream ID
• opcode, for example 0x00 for ERROR or 0x03 for AUTHENTICATE
• the length of the message

When messages are sent down the wire, they are decoded in sequence so these frames:

    | frame 8 header    | frame 8 body  | frame 9 header    | frame 9 body  |
----+---+---+---+---+---+---------------+---+---+---+---+---+---------------+----
... | v | f | s | o | l |   <payload>   | v | f | s | o | l |   <payload>   | ...
----+---+---+---+---+---+---------------+---+---+---+---+---+---------------+----

get decoded as:

• Parse header for frame 8 starting with version
• Parse the rest of the header
• Process the body of frame 8
• Parse header for frame 9 starting with version
• Parse the rest of the header
• Process the body of frame 9

The problem is when the body of a frame is larger than the maximum message size, it "overflows" into the start of the next frame. When the next frame gets parsed, part of the last frame gets picked up when it is expecting to get the version. But since the version in the header doesn't match any of the valid values, the driver returns an "unsupported protocol version" error because it doesn't recognise the version in the frame header.

I think this happens when reading or writing an unexpectedly large amount of data that message goes beyond the maximum frame size. Without knowing the query + partition that triggered the error, it is very hard for a DBA to determine the cause and therefore fix the offending partition. Cheers!