[
https://issues.apache.org/jira/browse/CASSANDRA-18424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18098537#comment-18098537
]
Josh McKenzie commented on CASSANDRA-18424:
-------------------------------------------
Linked a branch of this impl rebased on trunk as of this morning, all existing
new happy path and bespoke fuzzing paging tests passing.
Outstanding work is:
* Confirming this implementation plays nicely with Short Read Protection.
Specifically in mixed version clusters, mixed configuration clusters (i.e. some
nodes w/it enabled some not), and various data and tombstone density topologies
(i.e. all tombstones in the block being short-circuited by paging across
tombstones w/older nodes not having that and SRP kicking in, etc).
* Adding more in-jvm and upgrade dtests (mixed data, mismatched data, mixed
version mid-upgrade, post-upgrade mixed config, etc).
The goal on the above is to try and cover all our bases on the question of
"What happens if someone doesn't behave themselves and enables this on one node
on a new cluster and you query it?", along with other questions about how it
holds up under more and more divergent consistency w/data (i.e. one node sees
100k tombstones that another doesn't see and you go to read a page of data on
that range).
> Implement graceful paging across tombstones with short-circuit on paging
> rather than throwing TombstoneOverwhelmingExceptions
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18424
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: Messaging/Client, Messaging/Internode
> Reporter: Josh McKenzie
> Assignee: Josh McKenzie
> Priority: High
> Fix For: 6.x
>
>
> We implemented the hard stop with a {{TombstoneOverwhelmingException}} almost
> a decade ago since paging across many tombstones was the most common way for
> nodes to OOM as they iterated across all this data during queries and paging.
> With our current implementations and architecture / codebase, we should be
> able to combine the {{StoppingTransformation}} and existing {{clustering}}
> blob we pass back to clients to allow clients to optionally page across
> tombstones when using the async api via the driver and short-circuit a page
> when they hit the tombstone failure threshold rather than throwing a
> {{{}TombstoneOverwhelmingException{}}}. This would allow for more flexible
> data modeling on users' side as well as removing one of the fairly rough
> edges of our API's we're currently constrained by.
> Making sure this is correct will require extensive fuzz-testing of
> pagination; this should likely happen in the Harry project but we could also
> have a bespoke model / implementation in the C* codebase we rely on in the
> interim.
> Client warnings at the current default levels would remain; the gap between
> warn and "short-circuit pages" (100x ratio currently, 1000 vs. 100000) should
> be sufficient for clients to take action on their data models well before
> they hit this limit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
