cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5893) CqlParser throws StackOverflowError on bigger batch operation
Date Thu, 15 Aug 2013 15:57:48 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741090#comment-13741090
] 

Jonathan Ellis edited comment on CASSANDRA-5893 at 8/15/13 3:57 PM:
--------------------------------------------------------------------

bq. Shouldn't a batch be processed iteratively

Probably, although batch is not intended for making "bulk load" atomic or other Really Large
Sets of Rows.  Specifically, it's quite possible that this batch would time out even if it
were parsed without issue.
                
      was (Author: jbellis):
    bq. Shouldn't a batch be processed iteratively

Probably, but if your batch is large enough to stackoverflow, you're probably Doing It Wrong.
 It's not intended for making "bulk load" atomic, for instance.
                  
> CqlParser throws StackOverflowError on bigger batch operation
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-5893
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5893
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Vincent Mallet
>            Assignee: Aleksey Yeschenko
>             Fix For: 1.2.9
>
>
> We are seeing a problem with CQL3/Cassandra 1.2.8 where a large batch operation causes
the CqlParser to throw a StackOverflowError (-Xss180k initially, then -Xss325k).
> Shouldn't a batch be processed iteratively to avoid having to bump stack sizes to unreasonably
large values?
> Here is more info from the original problem description:
> <<<
> It looks like the CqlParser in 1.2.8 (probably 1.2.x, but i didn't look) is implemented
recursively in such a way that large batch statements blow up the stack. We, of course on
a Friday night, have a particular piece of code that's hitting a degenerate case that creates
a batch of inserts with a VERY large number of collection items, and it manifests as a StackOverflow
coming out the cass servers:
> java.lang.StackOverflowError
>        at org.apache.cassandra.cql3.CqlParser.value(CqlParser.java:5266)
>        at org.apache.cassandra.cql3.CqlParser.term(CqlParser.java:5627)
>        at org.apache.cassandra.cql3.CqlParser.set_tail(CqlParser.java:4807)
>        at org.apache.cassandra.cql3.CqlParser.set_tail(CqlParser.java:4813)
>        at org.apache.cassandra.cql3.CqlParser.set_tail(CqlParser.java:4813)
>        at org.apache.cassandra.cql3.CqlParser.set_tail(CqlParser.java:4813)
>        at org.apache.cassandra.cql3.CqlParser.set_tail(CqlParser.java:4813)
>        at org.apache.cassandra.cql3.CqlParser.set_tail(CqlParser.java:4813)
>        at org.apache.cassandra.cql3.CqlParser.set_tail(CqlParser.java:4813)
> 	...
> 	
> I think in the short term I can give up the atomicity of a batch in this code and kind
of suck it up, but obviously I'd prefer not to. I'm also not sure if I kept a single batch,
but split this into smaller pieces in each statement, whether that would still fail. I'm guessing
I could also crank the hell out of the stack size on the servers, but that feels pretty dirty.
> It seems like the CqlParser should probably be implemented in a way that isn't quite
so vulnerable to this, though I fully accept that this batch is koo-koo-bananas.
> >>>
> Thanks!
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message