You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Vincent White (JIRA)" <ji...@apache.org> on 2019/01/09 03:09:00 UTC

[jira] [Updated] (CASSANDRA-14365) Commit log replay failure for static columns with collections in clustering keys

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

Vincent White updated CASSANDRA-14365:
--------------------------------------
    Description: 
In the old storage engine, static cells with a collection as part of the clustering key fail to validate because a 0 byte collection (like in the cell name of a static cell) isn't valid.

To reproduce:

1.
{code:java}
CREATE TABLE test.x (
    id int,
    id2 frozen<map<text, text>>,
    st int static,
    PRIMARY KEY (id, id2)
);

INSERT INTO test.x (id, st) VALUES (1, 2);
{code}
2.
 Kill the cassandra process

3.
 Restart cassandra to replay the commitlog

Outcome:
{noformat}
ERROR [main] 2018-04-05 04:58:23,741 JVMStabilityInspector.java:99 - Exiting due to error while processing commit log during initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: Unexpected error deserializing mutation; saved to /tmp/mutation3825739904516830950dat.  This may be caused by replaying a mutation against a table with the same name but incompatible schema.  Exception follows: org.apache.cassandra.serializers.MarshalException: Not enough bytes to read a set
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:638) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:565) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:517) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:397) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:143) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) [main/:na]
        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:284) [main/:na]
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:533) [main/:na]
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:642) [main/:na]


{noformat}
I haven't investigated if there are other more subtle issues caused by these cells failing to validate other places in the code, but I believe the fix for this is to check for 0 byte length collections and accept them as valid as we do with other types.

I haven't had a chance for any extensive testing but this naive patch seems to have the desired affect. 


||Patch||
|[2.2 PoC|https://github.com/vincewhite/cassandra/commits/zero_length_collection]|


  was:
In the old storage engine, static cells with a collection as part of the clustering key fail to validate because a 0 byte collection (like in the cell name of a static cell) isn't valid.

To reproduce:

1.
{code:java}
CREATE TABLE test.x (
    id int,
    id2 frozen<map<text, text>>,
    st int static,
    PRIMARY KEY (id, id2)
);

INSERT INTO test.x (id, st) VALUES (1, 2);
{code}
2.
 Kill the cassandra process

3.
 Restart cassandra to replay the commitlog

Outcome:
{noformat}
ERROR [main] 2018-04-05 04:58:23,741 JVMStabilityInspector.java:99 - Exiting due to error while processing commit log during initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: Unexpected error deserializing mutation; saved to /tmp/mutation3825739904516830950dat.  This may be caused by replaying a mutation against a table with the same name but incompatible schema.  Exception follows: org.apache.cassandra.serializers.MarshalException: Not enough bytes to read a set
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:638) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:565) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:517) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:397) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:143) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) [main/:na]
        at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) [main/:na]
        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:284) [main/:na]
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:533) [main/:na]
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:642) [main/:na]


{noformat}
I haven't investigated if there are other more subtle issues caused by these cells failing to validate other places in the code, but I believe the fix for this is to check for 0 byte length collections and accept them as valid as we do with other types.

I haven't had a chance for any extensive testing but this naive patch seems to have the desired affect. 


||Patch||
|[2.2 PoC Patch|https://github.com/vincewhite/cassandra/commits/zero_length_collection]|



> Commit log replay failure for static columns with collections in clustering keys
> --------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-14365
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14365
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/Core
>            Reporter: Vincent White
>            Assignee: Vincent White
>            Priority: Major
>
> In the old storage engine, static cells with a collection as part of the clustering key fail to validate because a 0 byte collection (like in the cell name of a static cell) isn't valid.
> To reproduce:
> 1.
> {code:java}
> CREATE TABLE test.x (
>     id int,
>     id2 frozen<map<text, text>>,
>     st int static,
>     PRIMARY KEY (id, id2)
> );
> INSERT INTO test.x (id, st) VALUES (1, 2);
> {code}
> 2.
>  Kill the cassandra process
> 3.
>  Restart cassandra to replay the commitlog
> Outcome:
> {noformat}
> ERROR [main] 2018-04-05 04:58:23,741 JVMStabilityInspector.java:99 - Exiting due to error while processing commit log during initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: Unexpected error deserializing mutation; saved to /tmp/mutation3825739904516830950dat.  This may be caused by replaying a mutation against a table with the same name but incompatible schema.  Exception follows: org.apache.cassandra.serializers.MarshalException: Not enough bytes to read a set
>         at org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:638) [main/:na]
>         at org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:565) [main/:na]
>         at org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:517) [main/:na]
>         at org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:397) [main/:na]
>         at org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:143) [main/:na]
>         at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) [main/:na]
>         at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) [main/:na]
>         at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:284) [main/:na]
>         at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:533) [main/:na]
>         at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:642) [main/:na]
> {noformat}
> I haven't investigated if there are other more subtle issues caused by these cells failing to validate other places in the code, but I believe the fix for this is to check for 0 byte length collections and accept them as valid as we do with other types.
> I haven't had a chance for any extensive testing but this naive patch seems to have the desired affect. 
> ||Patch||
> |[2.2 PoC|https://github.com/vincewhite/cassandra/commits/zero_length_collection]|



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org