cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
Date Fri, 22 Jul 2016 09:56:21 GMT


Stefania commented on CASSANDRA-9318:

bq. Nope, you can actually implement such kind of strategy after my latest changes to the
state interface: you just have to keep recording per-replica state, and then eventually compute
a global coordinator state at back-pressure application.

Except the state may have nothing to do with a replica but let's leave it for now, I'm fine
with this.

bq. I ignored it on purpose as that's supposed to be for non mutations.

HintsDispatcher.Callback goes through the other one. Also, it is not consistent with the fact
that supportsBackPressure() is defined at the callback level.

bq. This can't actually happen. Given the same replica group (token range), the replicas are
sorted in stable rate limiting order, which means the same fast/slow replica will be picked
each time for a given back-pressure window; obviously, the replica order might change at the
next window, but that's by design and then all mutations will converge again to the same replica:
makes sense?

But the time windows of replicas do not necessarily match, they might be staggered. For example
replicas 1, 2 and 3 acquired a window for mutation A at the same time, then replicas 2, 3,
4 are used for mutation B, in this case only 3 and 4 will acquire the window because 2 acquired
it earlier, so the order may change even during a window. Or does it work by approximation,
assuming we send mutations to all replicas frequently enough?

> Bound the number of in-flight requests at the coordinator
> ---------------------------------------------------------
>                 Key: CASSANDRA-9318
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Local Write-Read Paths, Streaming and Messaging
>            Reporter: Ariel Weisberg
>            Assignee: Sergio Bossa
>         Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, limit.btm,
> It's possible to somewhat bound the amount of load accepted into the cluster by bounding
the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding bytes and requests
and if it reaches a high watermark disable read on client connections until it goes back below
some low watermark.
> Need to make sure that disabling read on the client connection won't introduce other

This message was sent by Atlassian JIRA

View raw message