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 Wed, 13 Jul 2016 13:45:21 GMT

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

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

bq. Hints are not a solution for chronically overloaded clusters where clients ingest faster
than replicas can consume

That is the situation I describe in scenario 3, which is the problem I opened this ticket
to solve.  So, I agree that scenario is a problem, but I don't think this proposal is a very
good solution for that, and it causes other problems in the other two (non-global-overload)
scenarios.

bq. I think we do solve that, actually in a better way, which takes into consideration all
replicas, not just the coordinator capacity of acting as a buffer, unless I'm missing a specific
case you're referring to?

I honestly don't see what is "better" about a "slow every write down to the speed of the slowest,
possibly sick, replica" approach.  Defining a simple high water mark on requests in flight
should be much simpler without the negative side effects.

> 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