cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-10219) KeyCache deserialization doesn't properly read indexed entries
Date Fri, 28 Aug 2015 13:45:46 GMT


Jonathan Ellis updated CASSANDRA-10219:
    Assignee: Branimir Lambov

> KeyCache deserialization doesn't properly read indexed entries
> --------------------------------------------------------------
>                 Key: CASSANDRA-10219
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Branimir Lambov
>             Fix For: 2.1.x
> When we write the key cache, we write the RowIndeEntry entirely, as can be seen in {{CacheService.KeyCacheSerializer.serialize}}:
> {noformat}
> ByteBufferUtil.writeWithLength(key.key, out);
> out.writeInt(key.desc.generation);
> out.writeBoolean(true);
> key.desc.getFormat().getIndexSerializer(cfm, key.desc.version, SerializationHeader.forKeyCache(cfm)).serialize(entry,
> {noformat}
> When we deserialize such entry, we have the case where an entry correspon to a sstable
that doesn't exist anymore (presumably, it's been deleted between the last cache saving and
the restart that triggers the cache loading), which goes this way:
> {noformat}
> ByteBuffer key =, keyLength);
> int generation = input.readInt();
> SSTableReader reader = findDesc(generation, cfs.getSSTables(SSTableSet.CANONICAL));
> input.readBoolean(); // backwards compatibility for "promoted indexes" boolean
> if (reader == null)
> {
>     RowIndexEntry.Serializer.skipPromotedIndex(input);
>     return null;
> }
> {noformat}
> But the thing is, {{RowIndexEntry.Serializer.skipPromotedIndex}} doesn't skip a full
{{RowIndexEntry}}, it doesn't skip the position in particular, and so as far as I can tell,
that part is buggy. I believe we should call {{RowIndexEntry.Serializer.skip}}.
> I'll note that I just noticed this while reading the code but I haven't reproduced that
problem personally. I also haven't pin-pointed the exact source of that problem, but it's
been there for a while as far as I can tell. At the same time, the condition to reach that
branch is probably pretty uncommon, and failure to load the key cache does not prevent the
node from starting and it doesn't even seem that we log an error (we log at DEBUG, maybe we
should log at WARN), which would explain nobody reporting this.

This message was sent by Atlassian JIRA

View raw message