cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mck (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-12351) IllegalStateException: empty rows returned when reading system.schema_keyspaces
Date Tue, 02 Aug 2016 11:21:20 GMT

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

mck edited comment on CASSANDRA-12351 at 8/2/16 11:21 AM:
----------------------------------------------------------

{quote}It's true we should probably call removedDeletedCF but I don't think I understand why
not doing so would break LegacySchemaTables. I mean, if removeDeleteldCF makes a difference
compared to just purgeTombstones, that imply the partition is empty and has only purgeable
top-level or range tombstones (those are the only things purgeTombstones removes). But such
partition shouldn't create any result on the CQL front, whether or not we do any purging,
and as UntypedResultSet uses the ResultSet processed by CQL, this shouldn't make any difference
to createKeyspaceFromSchemaPartition.{quote}

It makes a difference when it gets to {{readSchemaFromSystemTables(..)}} and doesn't skip
the "empty" row because {{isEmptySchemaPartition(partition)}} only checks for a null cf. A
quick scan through the code gave me the impression that {{row.cf == null}} was checked in
places while {{!partition.cf.hasColumns() && !isMarkedForDelete()}} wasn't. 

If the code is /sensitive/ in this way maybe adding some assert statements into CFS would
be a good idea, like
{{assert cf == null || cf.hasColumns() || cf.isMarkedForDelete()}}


was (Author: michaelsembwever):
{quote}It's true we should probably call removedDeletedCF but I don't think I understand why
not doing so would break LegacySchemaTables. I mean, if removeDeleteldCF makes a difference
compared to just purgeTombstones, that imply the partition is empty and has only purgeable
top-level or range tombstones (those are the only things purgeTombstones removes). But such
partition shouldn't create any result on the CQL front, whether or not we do any purging,
and as UntypedResultSet uses the ResultSet processed by CQL, this shouldn't make any difference
to createKeyspaceFromSchemaPartition.{quote}

It makes a difference when it gets to {{readSchemaFromSystemTables(..)}} and doesn't skip
the "empty" row because {{isEmptySchemaPartition(partition)}} only checks for a null cf. A
quick scan through the code gave me the impression that {{row.cf == null}} was checked in
places while {{!partition.cf.hasColumns() && !isMarkedForDelete()}} wasn't. 

If the code is /sensitive/ in this way maybe adding some assert statements into CF would be
a good idea, like
{{assert hasColumns() || isMarkedForDelete()}}

> IllegalStateException: empty rows returned when reading system.schema_keyspaces
> -------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-12351
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12351
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths
>            Reporter: mck
>            Assignee: mck
>
> After 2.2.6 the following error is thrown during startup, resulting in Cassandra not
starting.
> {noformat}
> CassandraDaemon.java:644 - Exception encountered during startup
> java.lang.IllegalStateException: One row required, 0 found
> at org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:77)
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartition(LegacySchemaTables.java:758)
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.schema.LegacySchemaTables.createKeyspaceFromSchemaPartitions(LegacySchemaTables.java:737)
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.schema.LegacySchemaTables.readSchemaFromSystemTables(LegacySchemaTables.java:219)
~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:117) ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:107) ~[apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:215) [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:522) [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:631) [apache-cassandra-2.2.7.jar:2.2.7-SNAPSHOT]
> {noformat}
> In {{LegacySchemaTables.readSchemaFromSystemTables(..)}} the call to {{getSchemaPartitionsForTable(KEYSPACES)}}
is now (since 2.2.6) returning more rows. The additional rows are empty.
> These rows are coming out of the row iterator post 2.2.6, where they were not in 2.2.6.
> This issue was raised on the mailing list [here|http://mail-archives.apache.org/mod_mbox/cassandra-user/201607.mbox/%3C776766150.5940472.1469733214785.JavaMail.yahoo@mail.yahoo.com%3E].



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

Mime
View raw message