[
https://issues.apache.org/jira/browse/CASSANDRA-12453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15438796#comment-15438796
]
Robert Stupp commented on CASSANDRA-12453:
------------------------------------------
For the hotKeyIterator, OHC implementation requests {{n / #-of-segments}} keys
per hash segment. This is a trade-off to limit the number of locks and accesses
to each segment for each iterator. This means that the number of returned
entries is just a best-effort and the requested number of entries is more or
less a hint. In the extreme case, It may also return slightly more results.
It should be fine for production cases, when many keys are requested.
In order to make the test non-flaky, it would help to see the actual utest
errors (haven't seen any errors in the last CI tests).
> AutoSavingCache does not store required keys making RowCacheTests Flaky
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-12453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12453
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: sankalp kohli
> Priority: Minor
>
> RowCacheTests were flaky and while investigating, I found that it does not
> store all the keys to disk.
> The reason is that we use OHCache and call hotKeyIterator on it. This is not
> guaranteed to return the number of keys we want. Here is the documentation
> from OHCache
> /**
> * Builds an iterator over the N most recently used keys returning
> deserialized objects.
> * You must call {@code close()} on the returned iterator.
> * <p>
> * Note: During a rehash, the implementation might return keys twice
> or not at all.
> * </p>
> */
> CloseableIterator<K> hotKeyIterator(int n);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
