[
https://issues.apache.org/jira/browse/CASSANDRA-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15243842#comment-15243842
]
Benedict commented on CASSANDRA-11452:
--------------------------------------
Yeah, another possibility is to pick a random hash table bucket's first element
for the guard, or do this for a proportion of admissions.
Some overly complex options are also to maintain a mean/median of the last X
LRU items, or to decide a %ile given the sketch and map size, calculate it from
the sketch periodically, and admit only those above it.
However I'm not sure Cassandra cares too much about a concerted attacker for
this since it would be very hard to predict what the keys would be (you'd need
the random seed, the existing sstable layouts, other keys and the ability to
directly induce load on the server, and even then it would be challenging). So
long as there is no realistic accidental way for it to happen I'd say we're
good.
One slight variant to consider is using an xor of the victim and candidate
hashes for our RNF. This is likely quicker, should be perfectly safe to attack
for any good hash function (especially post-spread), and would have the nice
property of determinism for unit tests.
> Cache implementation using LIRS eviction for in-process page cache
> ------------------------------------------------------------------
>
> Key: CASSANDRA-11452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11452
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Reporter: Branimir Lambov
> Assignee: Branimir Lambov
>
> Following up from CASSANDRA-5863, to make best use of caching and to avoid
> having to explicitly marking compaction accesses as non-cacheable, we need a
> cache implementation that uses an eviction algorithm that can better handle
> non-recurring accesses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
