[
https://issues.apache.org/jira/browse/CASSANDRA-21092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050426#comment-18050426
]
Stefan Miklosovic commented on CASSANDRA-21092:
-----------------------------------------------
We might probably also detect what format that SSTable we go to import is of
and automatically add such a flag there already?
> Add --disable-zero-copy-streaming parameter to sstableloader
> ------------------------------------------------------------
>
> Key: CASSANDRA-21092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21092
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Tool/sstable
> Reporter: Paulo Motta
> Assignee: Paulo Motta
> Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When attempting to load legacy Cassandra 3.11 sstables into a Cassandra 5.0+
> cluster using sstableloader, the operation fails with a StreamException when
> zero-copy streaming is enabled (which is the default behavior). The root
> cause is an assertion error {{java.lang.AssertionError: Filter should not be
> serialized in old format at
> org.apache.cassandra.utils.BloomFilter.serialize(BloomFilter.java:67)}} that
> was introduced by CASSANDRA-17056 when it landed in the 5.0 branch.
> This is a regression from Cassandra 4.0 and 4.1, where zero-copy streaming
> works fine with legacy sstables. The changes in 5.0 introduced stricter
> validation that rejects the old bloom filter serialization format used in 3.x
> sstables, causing the streaming operation to fail.
> I'm not comfortable in removing the assertion and making a special case to
> skip the assertion for sstableloader would be invasive so I propose adding a
> new flag --disable-zero-copy-streaming to overcome this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
