cassandra-commits mailing list archives

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


Sergio Bossa commented on CASSANDRA-9318:


bq. OK, so we are basically saying other coordinator-based approaches won't be implemented
as a back-pressure strategy.

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.

bq. There's another overload of sendRR

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

bq. One final thought, now we have N rate limiters, and we call aquire(1) on only one of them.
For the next mutation we may pick another one and so forth.

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?

> 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