[
https://issues.apache.org/jira/browse/CASSANDRA-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790981#comment-14790981
]
Robert Stupp commented on CASSANDRA-10155:
------------------------------------------
One thing I didn’t recognize before is that I *think* using _ksAndCfName_
instead of _cfId_ introduces a possible data race condition. Imagine the
following sequence of operations:
# {{CREATE TABLE foo.bar …}}
# {{INSERT INTO foo.bar (pk, val) VALUES (1,1)}}
# {{SELECT * FROM foo.bar WHERE pk=1}} returns one row as expected
# _row cache saved to disk_
# {{DROP TABLE foo.bar}}
# {{CREATE TABLE foo.bar …}}
# {{SELECT * FROM foo.bar WHERE pk=1}} returns no rows as expected
# _stop node_
# _start node, caches are loaded_
# {{SELECT * FROM foo.bar WHERE pk=1}} returns one row - as row-cache contains
the row
I think similar problems are possible but not that easily reproducible with key
and counter caches. Key cache is probably the worst candidate as bloom filter
check is executed before key cache is consulted.
I think we have to calculate the schema digest before starting to save the
cache and serialize that digest with in the saved-cache file. Upon loading the
cache file, compare the digest of the current schema against the digest in the
saved cache file and prevent loading if the digests don’t match.
NITs:
* {{AutoSavingCache.CacheSerializer}}: remove abstract from interface methods.
* {{RowCacheKey.compareTo}}: we should remove {{Comparable}} from
{{RowCacheKey}} as it seems unused (at least in 3.0).
Beside that all patches LGTM
> 2i key cache load fails
> -----------------------
>
> Key: CASSANDRA-10155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10155
> Project: Cassandra
> Issue Type: Bug
> Reporter: Robert Stupp
> Assignee: Ariel Weisberg
> Fix For: 3.0.0 rc1, 2.1.10, 2.2.2
>
>
> CASSANDRA-9265 changed how key cache content is serialized to disk. It uses
> {{UUID cfId}} to generate the file path for each {{ColumnFamilyStore}}.
> Since {{cfId}} of a secondary index is the same as for the base table, the
> key-cache files for 2i's and the base are the same. This will/may lead to
> deserialization failures on restart for tables with at least one 2i.
> /cc [~aweisberg] [~danchia]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
