[jira] [Comment Edited] (CASSANDRA-5893) CqlParser throws StackOverflowError on bigger batch operation

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ 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