[
https://issues.apache.org/jira/browse/CASSANDRA-21763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128547#comment-18128547
]
Reza Taroosheh edited comment on CASSANDRA-21763 at 10/18/26 11:06 PM:
-----------------------------------------------------------------------
Patch for cassandra-6.0: [https://github.com/apache/cassandra/pull/5268]
- {{CBUtil.writeString()}} now allows up to 65535 bytes, matching the unsigned
{{[short]}} length in the protocol spec and {{{}readString(){}}}.
- {{ClientWarn}} is also truncated by chars rather than UTF-8 bytes, so a long
non-ASCII warning could still exceed the limit or throw
{{{}StringIndexOutOfBoundsException{}}}. It now truncates by encoded length
without splitting characters.
{{Added tests in CBUtilTest and a new ClientWarnTest; they pass locally, as do
ClientWarningsTest and the ant check}} (GitHub Actions).
Confirmed: reverting the fix makes the new tests fail with {{String too large;
expected 65535 <= 32767}}, matching the report.
Affected: 6.0 and trunk; 5.0 is not affected. The patch merges cleanly to trunk
apart from the usual {{CHANGES.txt}} conflict. I don't have access to
pre-commit CI; could a committer run it?
[~dcapwell] The check came from the CASSANDRA-20234 merge. Would you be able to
review?
was (Author: JIRAUSER313034):
Patch for cassandra-6.0: [https://github.com/apache/cassandra/pull/5268]
- {{CBUtil.writeString()}} now allows up to 65535 bytes, matching the unsigned
{{[short]}} length in the protocol spec and {{{}readString(){}}}.
- {{ClientWarn}} is also truncated by chars rather than UTF-8 bytes, so a long
non-ASCII warning could still exceed the limit or throw
{{{}StringIndexOutOfBoundsException{}}}. It now truncates by encoded length
without splitting characters.
{{Added tests in CBUtilTest and a new ClientWarnTest; they pass locally, as do
ClientWarningsTest and the ant check}} (GitHub Actions).
Confirmed: reverting the fix makes the new tests fail with String too large;
expected 65535 <= 32767, matching the report.
Affected: 6.0 and trunk; 5.0 is not affected. The patch merges cleanly to trunk
apart from the usual {{CHANGES.txt}} conflict. I don't have access to
pre-commit CI; could a committer run it?
[~dcapwell] The check came from the CASSANDRA-20234 merge. Would you be able to
review?
> Responses with a string between 32768 and 65535 bytes fail, e.g. a long
> client warning
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21763
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Reporter: Nadav Har'El
> Assignee: Reza Taroosheh
> Priority: Normal
> Fix For: 6.0.x, 7.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since CASSANDRA-20234, {{CBUtil.writeString()}} on the cassandra-6.0 branch
> and trunk rejects any string longer than {{Short.MAX_VALUE}} (32767 bytes):
> {code:java}
> Preconditions.checkArgument(length <= Short.MAX_VALUE, ... "String too large;
> expected %d <= %d" ...);
> {code}
> But the native protocol's [string] has an unsigned 2-byte length, so it may
> be up to 65535 bytes, and {{ClientWarn}} still truncates warnings to
> {{FBUtilities.MAX_UNSIGNED_SHORT}} (65535). So a warning between 32768 and
> 65535 bytes makes the response fail with:
> {noformat}
> java.lang.IllegalArgumentException: String too large; expected 65535 <= 32767
> {noformat}
> and the client never gets a response, and times out. For example, a batch
> over the batch_size_warn_threshold that writes to a few hundred tables with
> long names gets such a warning, because the warning lists every table.
> Reproduced on Cassandra 6.0-alpha2. Cassandra 5.0.9 handles the same request
> correctly (its {{writeString()}} has no such check), returning the warning
> truncated, ending with " [truncated]".
> Either {{writeString()}} should allow up to 65535 bytes, or {{ClientWarn}}
> (and other callers) must truncate to 32767.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
