cassandra-commits mailing list archives

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


Benedict commented on CASSANDRA-9318:

bq. This in no way affects our contract or guarantees, since we don't do anything at all in
the intervening period except consume memory.
bq. The whole point is that coordinators are falling over from OOM. This isn't just something
we can wave away as negligible.

I was referring here to the status quo, FTR.

Also FTR, we do clearly state hints are "best effort" (they also aren't guaranteed to be persisted),
so as far as contracts / guarantees are concerned, I don't know we make any (and I wasn't
aware of this one). It would be really helpful for these (and many other) discussions if all
of the assumptions, contracts and guarantees we make about correctness and delivery were made
available in a single clearly spelled out document.

> Bound the number of in-flight requests at the coordinator
> ---------------------------------------------------------
>                 Key: CASSANDRA-9318
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message