[
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)
