cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-2571) Check for null super column for SC CF in ThriftValidation (and always validate the sc key)
Date Wed, 27 Apr 2011 16:52:03 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-2571:
----------------------------------------

    Attachment: 0001-Improve-ThriftValidation.patch

Turns out this is not a counter related bug. We just don't check when doing a (single) insert
(and thus a add) on a super CF that the super column is not null.

Attached patch add a system test and fix it. It also fix another hole in ThriftValidation
where the sc key was not validated. The patch is against 0.7 because it's not 0.8 specific.

Note that in 0.8 the cli "hides" this error for non counter column, but it is still not counter
specific. The fact that the cluster is then "in a bad state", is because since we don't refuse
the insert, some insert with a 'null' key is inserted in the column family map and thus messed
up following insert (I think at least, haven't check super closely).

> Check for null super column for SC CF in ThriftValidation (and always validate the sc
key)
> ------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-2571
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2571
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0, 0.8 beta 1
>            Reporter: Mike Bulman
>            Assignee: Sylvain Lebresne
>             Fix For: 0.7.6, 0.8.0
>
>         Attachments: 0001-Improve-ThriftValidation.patch
>
>
> Run the following via cli:
> {noformat}
> [default@test] use test;
> Authenticated to keyspace: test
> [default@test] create column family super with column_type=Super and default_validation_class=CounterColumnType;
> d41df8e0-7055-11e0-0000-242d50cf1fbf
> Waiting for schema agreement...
> ... schemas agree across the cluster
> [default@test] incr super['0']['0'];
> Value incremented.
> [default@test] incr super['0']['0']['0'];
> null
> {noformat}
> Obviously the first incr call is invalid, even though it reports otherwise, as well as
generates this exception:
> {noformat}
> ERROR 17:38:05,871 Fatal exception in thread Thread[COMMIT-LOG-WRITER,5,main]
> java.lang.RuntimeException: java.lang.ClassCastException: org.apache.cassandra.db.CounterColumn
cannot be cast to org.apache.cassandra.db.SuperColumn
>         at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
>         at java.lang.Thread.run(Thread.java:636)
> Caused by: java.lang.ClassCastException: org.apache.cassandra.db.CounterColumn cannot
be cast to org.apache.cassandra.db.SuperColumn
>         at org.apache.cassandra.db.SuperColumnSerializer.serialize(SuperColumn.java:353)
>         at org.apache.cassandra.db.SuperColumnSerializer.serialize(SuperColumn.java:337)
>         at org.apache.cassandra.db.ColumnFamilySerializer.serializeForSSTable(ColumnFamilySerializer.java:88)
>         at org.apache.cassandra.db.ColumnFamilySerializer.serialize(ColumnFamilySerializer.java:74)
>         at org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:353)
>         at org.apache.cassandra.db.RowMutation.getSerializedBuffer(RowMutation.java:236)
>         at org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:111)
>         at org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:480)
>         at org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:49)
>         at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>         ... 1 more
> {noformat}
> But the second, proper incr call results in a bunch of exceptions and not a real increment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message