cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
Date Sun, 28 Jun 2015 15:14:05 GMT

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

Benedict commented on CASSANDRA-9318:
-------------------------------------

bq. shedding is strictly worse

If we can do so without affecting our availability guarantees, sure.

bq. the contract 

We already drop hints on the floor if they cannot keep up.

To be clear: all I'm effectively suggesting is we "hint" (including the hinting step that
drops hints\*) earlier. This in no way affects our contract or guarantees, since we don't
do anything at all in the intervening period except consume memory. All we do is wait until
the timeout expires and then hint. This simply preempts the timer and hints immediately, possibly
resulting in the message being delivered via hints when it was delivered successfully (but
very late) first time around, but also possibly resulting in the hint being dropped, as it
could be at either time.

\* except that we can probably make this decision _less_ pessimistic than it is currently,
with better visibility on overall resource utilisation.

> 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
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>             Fix For: 2.2.x
>
>
> 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