cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Jones <MJo...@imagehawk.com>
Subject RE: 0.6.1 insert 1B rows, crashed when using py_stress
Date Tue, 20 Apr 2010 17:19:33 GMT
I would think this is on the roadmap, just not available yet.  It can be managed by adjusting
the Heap size (to a large degree).

-----Original Message-----
From: Tatu Saloranta [mailto:tsaloranta@gmail.com]
Sent: Tuesday, April 20, 2010 12:18 PM
To: user@cassandra.apache.org
Subject: Re: 0.6.1 insert 1B rows, crashed when using py_stress

On Mon, Apr 19, 2010 at 7:12 PM, Brandon Williams <driftx@gmail.com> wrote:
> On Mon, Apr 19, 2010 at 9:06 PM, Schubert Zhang <zsongbo@gmail.com> wrote:
>>
>> 2. Reject the request when be short of resource, instead of throws OOME
>> and exit (crash).
>
> Right, that is the crux of the problem  It will be addressed here:
> https://issues.apache.org/jira/browse/CASSANDRA-685

I think it would be great to get such "graceful degradation"
implemented: first thing any service should do is to protect itself
against meltdown.
Clients are better served by getting 50x responses (or rather its
equivalent for thrift), to indicate transient overload, than get
system into GC death spiral, where request time out but still consume
significant amounts of resources. Especially since returning error
response is usually rather cheap compared to doing full processing.
Also it should be then easy to hook up failure information via JMX to
expose it and allow alarming.

But this is of course more difficult with distributed set up,
especially since different QoS for different request would help (for
example: communication between nodes & other things related to
"accepted" requests should have higher priority than new incoming
requests).

-+ Tatu +-

Mime
View raw message