Re: Out of memory on wide row read

Shame on me for not noticing that you uttered the magic anti-pattern word - Thrift. Yeah, the standard response to any inquiry concerning Thrift is always that you should be migrating to CQL3. -- Jack Krupansky On Tue, May 19, 2015 at 3:13 AM, Antoine Blanchet < a.blanc...@abc-arbitrage.com> wrot

Re: Out of memory on wide row read

The issue has been closed by Jonathan Ellis. The limit is useless in CQL because of the automatic paging feature , that's cool. But this feature will not be add to the Thrift API. Subject closed :). On Mon, May 18, 2015 at

Re: Out of memory on wide row read

Done, https://issues.apache.org/jira/browse/CASSANDRA-9413 . Feel free to improve the description, I've only copy/paste the first message from Kévin. Thanks. On Fri, May 15, 2015 at 9:56 PM, Alprema wrote: > I William file a jira for that, thanks > On May 12, 2015 10:15 PM, "Jack Krupansky" >

Re: Out of memory on wide row read

I William file a jira for that, thanks On May 12, 2015 10:15 PM, "Jack Krupansky" wrote: > Sounds like it's worth a Jira - Cassandra should protect itself from > innocent mistakes or excessive requests from clients. Maybe there should be > a timeout or result size (bytes in addition to count) lim

Re: Out of memory on wide row read

Sounds like it's worth a Jira - Cassandra should protect itself from innocent mistakes or excessive requests from clients. Maybe there should be a timeout or result size (bytes in addition to count) limit. Something. Anything. But OOM seems a tad unfriendly for an innocent mistake. In this particul

Re: Out of memory on wide row read

On Tue, May 12, 2015 at 8:43 AM, Kévin LOVATO wrote: > My question is the following: Is it possible to prevent Cassandra from > OOM'ing when a client does this kind of requests? I'd rather have an error > thrown to the client than a multi-server crash. > You can provide a default LIMIT clause, b

Out of memory on wide row read

Hi, We experienced a crash on our production cluster following a massive wide row read. A client tried to read a wide row (~4GB of raw data) without specifying any slice condition, which resulted in the crash of multiple nodes (as many as the replication factor) after long garbage collections. We