cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
Date Mon, 11 Jul 2016 15:42:11 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371010#comment-15371010
] 

Jonathan Ellis commented on CASSANDRA-9318:
-------------------------------------------

If I understand this approach correctly, you're looking at the ratio of sent to acknowledged
writes per replica, and throwing Unavailable if that gets too low for a given replica.  Very
clever.

One thing that worries me is, how do you distinguish between “node X is slow because we
are writing too fast and we need to throttle clients down” and “node X is slow because
it is dying, we need to ignore it and accept writes based on other replicas?”

I.e. this seems to implicitly push everyone to a kind of CL.ALL model once your threshold
triggers, where if one replica is slow then we can't make progress.

If we take a simpler approach of just bounding total outstanding requests to all replicas
per coordinator, then we can avoid overload meltdown while allowing CL to continue to work
as designed and tolerate as many slow replicas as the requested CL permits.

> Bound the number of in-flight requests at the coordinator
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-9318
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
>             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,
no_backpressure.png
>
>
> 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
issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message