[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604755#comment-14604755
]
Aleksey Yeschenko commented on CASSANDRA-9318:
----------------------------------------------
bq. We do not drop hints on the floor.
We don't explicitly, but they are still "best effort" - before CASSANDRA-6230,
and after CASSANDRA-6230, too.
Before, because of their brokenness truncating the whole table at first sign of
trouble, or disabling hints entirely, is the norm. Even if this hadn't been the
case, the way they are persisted - ttld by the lowest gc gs of all tables in
the mutation - means that there are many scenarios when we wouldn't replay what
we had persisted.
We also don't preserve a hint at all if a node is past hints window, and this
only affects CL.ANY.
CASSANDRA-6230 codifies this fact, and that makes having a separate file+ per
host feasible at all - without an intermediate shared log. As soon as we write
to a shared {{HintsBuffer}}, we consider a hint written.
> 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.1.x, 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)
