cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10855) Use Caffeine (W-TinyLFU) for on-heap caches
Date Sat, 31 Dec 2016 09:58:58 GMT


Robert Stupp commented on CASSANDRA-10855:

Unit tests look good. However, a couple of dtests fail - unfortunately a situation for which
we do not have a unit test.
Thing is that exception handing in caffeine is different now. It manifests for example in
the catch-clause in {{org.apache.cassandra.auth.PasswordAuthenticator#authenticate}}. The
loader calls {{queryHashedPassword}}, which throws {{org.apache.cassandra.auth.PasswordAuthenticator.NoSuchCredentialsException}}
(extends {{RuntimeException}}). I assume that caffeine just "passes" REs and does not wrap
it in an some {{ExecutionException}}.
Example assertion message from the dtests looks like that's the reason: _'\'Failed to authenticate
to Error from server: code=0100 \[Bad credentials\] message="Provided username
mike and/or password are incorrect"\' not found in \'Failed to authenticate to
Error from server: code=0000 \[Server error\] message="org.apache.cassandra.auth.PasswordAuthenticator$NoSuchCredentialsException"\'_

[~ben.manes] can you verify that REs are just passed through and don't get wrapped in caffeine's
loader mechanism?


> Use Caffeine (W-TinyLFU) for on-heap caches
> -------------------------------------------
>                 Key: CASSANDRA-10855
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Ben Manes
>              Labels: performance
>         Attachments: CASSANDRA-10855.patch, CASSANDRA-10855.patch
> Cassandra currently uses [ConcurrentLinkedHashMap|]
for performance critical caches (key, counter) and Guava's cache for non-critical (auth, metrics,
security). All of these usages have been replaced by [Caffeine|],
written by the author of the previously mentioned libraries.
> The primary incentive is to switch from LRU policy to W-TinyLFU, which provides [near
optimal|] hit rates. It performs particularly
well in database and search traces, is scan resistant, and as adds a very small time/space
overhead to LRU.
> Secondarily, Guava's caches never obtained similar [performance|]
to CLHM due to some optimizations not being ported over. This change results in faster reads
and not creating garbage as a side-effect.

This message was sent by Atlassian JIRA

View raw message