> The problem with generalizing things is if you’re behind on compaction,
reads get expensive, so you pause compaction completely, you’re SOL and
you’ll eventually have to throttle traffic to recover
Yeah - there's definitely quite a few ways this can go sideways, and this
is a good example that
The problem with generalizing things is if you’re behind on compaction, reads get expensive, so you pause compaction completely, you’re SOL and you’ll eventually have to throttle traffic to recoverThe SEDA model is bad at back pressure and deferred cost makes it non-obvious which resource to slow
I am definitely +1 on the ability to rate limit operations to tables and
keyspaces, and if we can do it at a granular level per user I'm +1 to that
as well. I think this would need to be exposed to the operator regardless
of any automatic rate limiter.
Thinking about the bigger picture for a
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
Checked
- signing correct
- checksums are correct
- source
Proposing the test build of Cassandra 4.0.12 for release.
sha1: af752fcd535ccdac69b9fed88047b2dd7625801e
Git: https://github.com/apache/cassandra/tree/4.0.12-tentative
Maven Artifacts:
