On Wed, Feb 5, 2014 at 7:32 PM, Edward Capriolo wrote:
> I agree you can not really ask your database to capacity plan for you.
> Cassandra does have backpressure of sorts if requests fail with
> TimedOutException or UnavailableException. You might be having a capacity
> problem.
>
> The way I wo
On Wed, Feb 5, 2014 at 6:55 PM, Robert Coli wrote:
> I think most deploys of Cassandra deal with this reality by carefully
> managing available capacity so that they don't risk getting in this
> situation.
This is what I have done in my production apps. Basically I have found
the system's sweet s
I agree you can not really ask your database to capacity plan for you.
Cassandra does have backpressure of sorts if requests fail with
TimedOutException or UnavailableException. You might be having a capacity
problem.
The way I would handle this is
1) prototype at scale (dark launches, similar ha
On Wed, Feb 5, 2014 at 6:14 AM, Ben Hood <0x6e6...@gmail.com> wrote:
> What is the general approach to this from a server perspective? Is
> there any flow control that the server can apply to back pressure onto
> the sending driver?
No. In theory the client could look at dynamic snitch scores, I
Hi,
A discussion has arisen in the gocql team about how to handle
saturation when CQL clients are sending in packets at a faster rate
than the Cassandra cluster can sustain.
What is the general approach to this from a server perspective? Is
there any flow control that the server can apply to back
