[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489927#comment-15489927
]
Sylvain Lebresne commented on CASSANDRA-9318:
---------------------------------------------
bq. If back pressure kicks in, then it may be that mutations are applied by all
replicas but the application receives a timeout nonetheless.
That's *not* specific to back-pressure and can perfectly happen today and
that's fine. Again, if your application *require* that the server answers
within say 500ms, the server should do so and not randomly fail that deadline
because back-pressure kicks-in. If the deadline you set as a user is too low
and you get timeouts too often, then it's your problem and you should either
reconsider your deadline because it's unrealistic, or increase your cluster
capacity. But I genuinely don't understand how not doing what the user
explicitly asks us to do would ever make sense.
bq. 1) We keep the timeout strict and change the back-pressure implementation
to wait at most the given timeout, and fail otherwise.
It's possible I'm totally missing a point you and Stefania are trying to make,
but it seems to me to be the only reasonable way. The timeout is a deadline the
user asks us to respect, it's the whole point of it, so it should always be
respected as strictly as possible. If the user sets it too low, his mistake
(and don't get me wrong, we should certainly educate user to avoid that mistake
through documentation as much as possible).
More generally though, that discussion seems to suggest that back-pressure
would make it harder for C* to respect a reasonable timeout. I'll admit that
sounds counter-intuitive to me as a functioning back-pressure should make it
_easier_ by smoothing things over when there is too much pressure.
> 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)
