cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5893) CqlParser throws StackOverflowError on bigger batch operation
Date Sun, 18 Aug 2013 00:19:48 GMT

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

Aleksey Yeschenko commented on CASSANDRA-5893:
----------------------------------------------

Never mind what I said earlier, sorry. A misunderstanding on my part. The size of the batch
doesn't matter, only the size of any set/map literal.

Stack overflow happens when parsing huge set and map literals (list literals are not affected).
Starting at around 24k elements with the default 1.2 -Xss. Now, while you probably shouldn't
be using literals this big, this *fits* within the 64k limit and should be supported.

And yeah, it can be done non-recursively. Will fix.
                
> 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