cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10155) 2i key cache load fails
Date Thu, 10 Sep 2015 22:52:47 GMT


Ariel Weisberg commented on CASSANDRA-10155:

bq. Regarding your comment in Schema.getColumnFamilyStoreIncludingIndexes() (3.0) ”Shouldn't
ask for a backing table if there is none so just throw?” - that’s actually a good question.
How’s that handled in 2.1/2.2? I think there should be a unit test that tests exactly this
behaviour - a C* 2i on one column and a custom, table-less index on another column. Only the
2i should get entries in the key-cache at all - non-table backed indexes must not.

Hah, well I was just going to let it NPE naively assuming that I haven't actually made anything
worse. I guess I might have since before it would get the base table. That's not a good assumption
so yeah I'll make a test.

bq. CacheKey: just thinking whether it’s better to replace Pair<String,String> ksAndCFName
with a byte[] ksAndCFName as it is cheaper to serialize and deserialize. OTOH you need some
object to pass to getColumnFamilyStoreIncludingIndexes(). Or put both byte[] and Pair fields
into CacheKey so that serialization can just use the byte[] but we still have the Pair available.
WDYT? (Latter applies to 2.2/3.0)
I'm not sure we can really win here? 

The problem with byte[] ksAndCFName is that everything else that uses the bimap in Schema
is going to have two strings and not the bytes.

When cache keys deserialize it will have the bytes, but not the Pair.

Someone has to be the loser if we change it.

bq. Field name ksAndCFName doesn’t make really clear that it can also contain the name of
the secondary index. ksAndCfAndMaybe2iName doesn’t feel better though - don’t even know
whether we have a known term for this at all.
Indexes are CFs that share a UUID with some other CFs. I don't see it as so ambiguous at that
stage. ksAndCFOr2i? Nothing about that makes me feel better :-)

> 2i key cache load fails
> -----------------------
>                 Key: CASSANDRA-10155
>                 URL:
>             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

View raw message