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:33:05 GMT

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

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

In fact, building on CASSANDRA-6230, it might be superior to immediately write to the hints
buffer (saving the serialization for passing to MS; this might also reduce serialization rather
than increase), and to mark the hint delivered when we receive the callback. 

On flushing hints, we can ignore any that have been delivered (which we would prefer to do
anyway). We ideally only flush the hints buffer after the timeout interval has elapsed, or
alternatively if we run out of a generous memory allowance. With some small tweaks we would
only need to keep a minimal piece of identifying information to invalidate the hint record,
even after it has been written to disk. This would ensure our behaviour is identical, except
with a guaranteed bound on memory utilisation (and increased capacity, since we can serialize
the hints off heap, and they will occupy much less space).

> 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