[
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
