[
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/%[email protected]%3E].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
