[jira] [Commented] (CASSANDRA-5893) CqlParser throws StackOverflowError on bigger batch operation
[ https://issues.apache.org/jira/browse/CASSANDRA-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13750416#comment-13750416 ] Vincent Mallet commented on CASSANDRA-5893: --- Great, thanks! 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 Attachments: 5893.txt 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
[jira] [Commented] (CASSANDRA-5893) CqlParser throws StackOverflowError on bigger batch operation
[ https://issues.apache.org/jira/browse/CASSANDRA-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746116#comment-13746116 ] Sylvain Lebresne commented on CASSANDRA-5893: - +1 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 Attachments: 5893.txt 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
[jira] [Commented] (CASSANDRA-5893) CqlParser throws StackOverflowError on bigger batch operation
[ https://issues.apache.org/jira/browse/CASSANDRA-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (CASSANDRA-5893) CqlParser throws StackOverflowError on bigger batch operation
[ https://issues.apache.org/jira/browse/CASSANDRA-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742838#comment-13742838 ] Jonathan Ellis commented on CASSANDRA-5893: --- Hmm. Can we at least catch the overflow and return InvalidRequest? 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
