cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8128) Exception when executing UPSERT
Date Fri, 09 Jan 2015 15:21:36 GMT


Sylvain Lebresne commented on CASSANDRA-8128:

What the stack trace is saying is that there is more bind marker in the query than there is
values (in other words, the client somehow didn't sent enough values). This should have failed
with a meaningful error, but said meaningful error is thrown by {{QueryProcess.process()}}
but it it appears that DSE bypass this method using it's own {{DseQueryHandler.process}} and
that might be missing the proper check. So I'd first report this through the DataStax support
so it gets fixed there (provided I'm right that the check is missing).

Now I suppose your real problem is why less values than needed were sent. It's a good question
but it's unlikely a server-side problem. It could a problem in your code, or it could be a
problem with your driver triggered by large batches. For instance, one thing that comes to
mind is that there is a hard limit in the protocol of 64K values per statement and the java
driver used to not validate that properly ([JAVA-515|]
which is fixed in more recent versions of the driver), so if your statement ends up having
more than that, it could trigger an overflow that silently trigger this problem.

Anyway, it's unlikely a server side problem (except for the validation problem, but unless
proved otherwise, Apache Cassandra does properly validate this case) so closing this. If you
have further elements that seems to indicate that Cassandra is to blame, feel free to reopen
with those elements.

> Exception when executing UPSERT
> -------------------------------
>                 Key: CASSANDRA-8128
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: API
>            Reporter: Jens Rantil
>            Priority: Critical
>              Labels: cql3
>             Fix For: 2.0.12
> I am putting a bunch of (CQL) rows into Datastax DSE 4.5.1-1. Each upsert is for a single
partition key with up to ~3000 clustering keys. I understand to large upsert aren't recommended,
but I wouldn't expect to be getting the following exception anyway:
> {noformat}
> ERROR [Native-Transport-Requests:4205136] 2014-10-16 12:00:38,668 (line
222) Unexpected exception during request
> java.lang.IndexOutOfBoundsException: Index: 1749, Size: 1749
>         at java.util.ArrayList.rangeCheck(
>         at java.util.ArrayList.get(
>         at org.apache.cassandra.cql3.Constants$Marker.bindAndGet(
>         at org.apache.cassandra.cql3.Constants$Setter.execute(
>         at org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(
>         at org.apache.cassandra.cql3.statements.BatchStatement.addStatementMutations(
>         at org.apache.cassandra.cql3.statements.BatchStatement.getMutations(
>         at org.apache.cassandra.cql3.statements.BatchStatement.execute(
>         at org.apache.cassandra.cql3.statements.BatchStatement.execute(
>         at org.apache.cassandra.cql3.QueryProcessor.processStatement(
>         at com.datastax.bdp.cassandra.cql3.DseQueryHandler.statementExecution(
>         at com.datastax.bdp.cassandra.cql3.DseQueryHandler.process(
>         at org.apache.cassandra.transport.messages.QueryMessage.execute(
>         at org.apache.cassandra.transport.Message$Dispatcher.messageReceived(
>         at
>         at
>         at$DefaultChannelHandlerContext.sendUpstream(
>         at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(
>         at
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> {noformat}

This message was sent by Atlassian JIRA

View raw message