[
https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283036#comment-17283036
]
Alex Petrov commented on CASSANDRA-16262:
-----------------------------------------
Given latest data points I would strongly advise against excluding this ticket
from 4.0. Running Harry for a relatively short amount of time, we've been able
to hit at three issues:
* Group By in-jvm paging issue:
https://issues.apache.org/jira/browse/CASSANDRA-16427
* Group By breaks range tombstone closer:
https://issues.apache.org/jira/browse/CASSANDRA-16431
* Reverse iteration + paging:
https://issues.apache.org/jira/browse/CASSANDRA-16435
I think we would've hit the first one without a fuzz tool, since it was a
relatively obvious one, but looking at the output from Harry it was almost
immediately clear what's going on, so I still consider its output useful.
Amount of human labour involved into producing scenarios that would trigger the
issues such as the other two is quite significant. As of now, we can't even
continue further testing of group by or reverse iteration with paging because
we're constantly hitting these two issues. It can be that we won't hit any
other ones, but I think we should at least exhaust the ability of current
generators and models to find bugs, especially given they are rather simple
compared to what we'd like to achieve in the future, and they're already
available.
> 4.0 Quality: Coordination & Replication Fuzz Testing
> ----------------------------------------------------
>
> Key: CASSANDRA-16262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16262
> Project: Cassandra
> Issue Type: Task
> Components: Test/fuzz
> Reporter: Caleb Rackliffe
> Priority: Normal
> Fix For: 4.0-rc
>
>
> CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on
> auditing the existing tests around coordination, replication, and
> read-repair, respectively. We've expanded existing test cases, added coverage
> around components that we've refactored along the way, and added in-JVM dtest
> upgrade tests where possible.
> What remains is verifying the distributed read and write paths in the face of
> common operational events, namely node restarts, bootstrapping, decommission,
> and cleanup. If we can find a way to simulate these events,
> [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate
> to host the verification logic itself.
> To keep things simple initially, I would propose that we start by testing
> simple read-only and write-only workloads (the former without read repair).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
