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

Mathijs Vogelzang commented on CASSANDRA-8786:
----------------------------------------------

The tables were probably originally created on version 1.x
We've only tried with cqlsh.
I've just done a "DESCRIBE" in cassandra-cli on our production table and the 
new one and the most suspicious difference is that on the production 
(non-working) table, one column name is listed like this:
{noformat}
(...)
  Column Name: account_id
          Validation Class: org.apache.cassandra.db.marshal.LongType
          Index Name: idx_accid
          Index Type: KEYS
  Column Name:  next_column_name
(...){noformat}

and on the newly created development table (the one without problems) it is
{noformat}
(...)
 Column Name: account_id
          Validation Class: org.apache.cassandra.db.marshal.LongType
          Index Name: idx_accid
          Index Type: KEYS
          Index Options: {}
  Column Name:  next_column_name
(...){noformat}

(Other minor differences are speculative retry NONE vs 99.0PERCENTILE, Read 
repair chance 0 vs 1 and Bloom filter FP chance default vs. 0.01, but the 
"Index Options" seems closer to where the problem probably lies to me)

> NullPointerException in ColumnDefinition.hasIndexOption
> -------------------------------------------------------
>
>                 Key: CASSANDRA-8786
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8786
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Cassandra 2.1.2
>            Reporter: Mathijs Vogelzang
>             Fix For: 2.1.4
>
>
> We have a Cassandra cluster that we've been using through many upgrades, and 
> thus most of our column families have originally been created by Thrift. We 
> are on Cassandra 2.1.2 now.
> We've now ported most of our code to use CQL, and our code occasionally tries 
> to recreate tables with "IF NOT EXISTS" to work properly on development / 
> testing environments.
> When we issue the CQL statement "CREATE INDEX IF NOT EXISTS index ON 
> "tableName" (accountId)" (this index does exist on that table already), we 
> get a {{DriverInternalError: An unexpected error occurred server side on 
> cass_host/xx.xxx.xxx.xxx:9042: java.lang.NullPointerException}}
> The error on the server is:
> {noformat}
>  java.lang.NullPointerException: null
>         at 
> org.apache.cassandra.config.ColumnDefinition.hasIndexOption(ColumnDefinition.java:489)
>  ~[apache-cassandra-2.1.2.jar:2.1.2]
>         at 
> org.apache.cassandra.cql3.statements.CreateIndexStatement.validate(CreateIndexStatement.java:87)
>  ~[apache-cassandra-2.1.2.jar:2.1.2]
>         at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:224)
>  ~[apache-cassandra-2.1.2.jar:2.1.2]
>         at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248) 
> ~[apache-cassandra-2.1.2.jar:2.1.2]
>         at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
>  ~[apache-cassandra-2.1.2.jar:2.1.2]
> {noformat}
> This happens every time we run this CQL statement. We've tried to reproduce 
> it in a test cassandra cluster by creating the table according to the exact 
> "DESCRIBE TABLE" specification, but then this NullPointerException doesn't 
> happon upon the CREATE INDEX one. So it seems that the tables on our 
> production cluster (that were originally created through thrift) are still 
> subtly different schema-wise then a freshly created table according to the 
> same creation statement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to