[
https://issues.apache.org/jira/browse/CASSANDRA-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715196#comment-14715196
]
Nate McCall commented on CASSANDRA-7910:
----------------------------------------
Pretty sure this issue in conjunction with the changes introduced in
CASSANDRA-9532 is triggering the following error after an {{2.0.13}} to
{{2.0.16}} upgrade on one node of a six node cluster:
{noformat}
ERROR [Native-Transport-Requests:11] 2015-07-29 18:00:50,344 Message.java (line
403) Unexpected exception during request; channel = [id: 0x599799a6,
/[redacted]:38306 => /[redacted]:9042]
java.lang.AssertionError
at org.apache.cassandra.cql3.ResultSet.addRow(ResultSet.java:63)
at
org.apache.cassandra.cql3.statements.Selection$ResultSetBuilder.build(Selection.java:330)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1189)
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:309)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:281)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:241)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:68)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:158)
at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:175)
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:321)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Note that we passed the statement parsing phase and made it all the way down
into an assertion error on the number of returned columns vs. what metadata
feels should be there. The rest of the cluster was moved up {{2.0.15}} (after
some bisecting brought up the scope of CASSANDRA-9532) and has been running w/o
issue. The one node is still running at {{2.0.16}} with transports off so we
can gather some debugging information with a custom build we just put up (for
which we'll enable binary for a bit to capture samples).
Given the impedance mismatch between these two issues and versions, I'm putting
this up here for posterity more than looking for a re-open. I'll update if we
nail down a specific case that can easily produce the error and provide a
work-around (most likely not using {{SELECT *...}} as previously mentioned). If
we can destill something into a patch, we'll create a new issue and put it
there.
> wildcard prepared statements are incorrect after a column is added to the
> table
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-7910
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7910
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Oded Peer
> Assignee: Tyler Hobbs
> Priority: Minor
> Labels: client-impacting
> Fix For: 2.1.3
>
> Attachments: 7910-2.1.txt, 7910-trunk.txt,
> PreparedStatementAfterAddColumnTest.java
>
>
> 1. Prepare a statement with a wildcard in the select clause.
> 2. Alter the table - add a column
> 3. execute the prepared statement
> Expected result - get all the columns including the new column
> Actual result - get the columns except the new column
> Attached a test using cassandra-unit
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
