[
https://issues.apache.org/jira/browse/CASSANDRA-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726103#comment-14726103
]
Ariel Weisberg commented on CASSANDRA-10155:
--------------------------------------------
[Have a 3.0 change for
this.|https://github.com/apache/cassandra/compare/trunk...aweisberg:C-10155-3.0?expand=1]
I need to make sure existing tests run, and then make sure all the new code is
tested.
I need to rebase it to 2.1 and then figure out the right way to get to merge
forward.
* There is now only one saved cache file for each kind of key (row, key,
counter)
* This means that loading of each kind of cache is single threaded. Previous
code loaded caches synchronously at startup so it was probably single threaded
anyways.
* Loading is async in its own thread for each cache so key and row cache can
load at the same time
* Caches could load concurrently with other startup activities, but there
didn't seem to be a desire to have that happen so startup blocks until they are
loaded
* Cache keys now contain the keyspace and CF name instead of UUID. There is no
footprint change for on heap caches because they are POJOs pointing to a
canonical object. Off heap will potentially see an increase in size and time
since it will have to store and decode two strings instead of a UUID.
* Schema now has a function that will look up a CF, even if it is an index,
correctly.
* Cache loading used to collect a future per cache entry in a list! For an off
heap cache that is larger than the Java heap this is a problem. Modified to
bound the number of pending reads and consume read results by loading them into
the cache as they come in.
* Promoted errors in loading caches to info level that were debug.
> 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)
