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

Vovodroid commented on CASSANDRA-10305:
---------------------------------------

Hi [Sam|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=beobal]!

If you take a look on the issue I would like to add that from my point of view 
problem is not crash itself (it may be related to my own build), but that 
released binary Cassandra can't not recover and start on somehow corrupted 
database. It would be nice if it will be able to recover such database, 
probably discard some unrecoverable keyspaces, but starting nevertheless.

Thanks.

> NullPointerException on database migration/load
> -----------------------------------------------
>
>                 Key: CASSANDRA-10305
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10305
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: CentOS 7.1/x64
>            Reporter: Vovodroid
>            Assignee: Sam Tunnicliffe
>            Priority: Critical
>         Attachments: crash.log, data.zip, startup.log
>
>
> I run some tests in C* 2.2.1 with script that launches cqlsh and feeds 
> commands to its stdin and gets results from stdout. Several cqlsh instances 
> are involved in parallel.
> Test includes creating and dropping the same keyspace several times.
> I need to add timeouts between feeding command and reading results, otherwise 
> tests fail. If this timeout too small Cassandra sometimes fails with 
> NullPointerException (see crash.log). 
> But what is worst, that after that Cassandra can not be started at all and 
> fail with the same error (see startup.log).
> What happens is that inside of *row.getString("type")* called from
> {code}
> LegacySchemaTables.createColumnFromColumnRow
> ..........................
> ColumnDefinition.Kind kind = deserializeKind(row.getString("type"));{code}
> *data.get(column)* returns null for table *excelsiour_amd__amd__.users*.
> Data causing this issue is in data.zip (no commit logs due to their size, but 
> I can give them if necessary).
> Just open zip in Cassandra folder (or where data is located in specific 
> environment) and start C*. (set Password



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

Reply via email to