[
https://issues.apache.org/jira/browse/CASSANDRA-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15789267#comment-15789267
]
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 127.0.0.1: Error from server: code=0100 \[Bad
credentials\] message="Provided username mike and/or password are incorrect"\'
not found in \'Failed to authenticate to 127.0.0.1: 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?
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:10855-caffeine-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-10855-caffeine-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-10855-caffeine-trunk-dtest/lastSuccessfulBuild/]
> Use Caffeine (W-TinyLFU) for on-heap caches
> -------------------------------------------
>
> Key: CASSANDRA-10855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10855
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Ben Manes
> Labels: performance
> Attachments: CASSANDRA-10855.patch, CASSANDRA-10855.patch
>
>
> Cassandra currently uses
> [ConcurrentLinkedHashMap|https://code.google.com/p/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|https://github.com/ben-manes/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|https://github.com/ben-manes/caffeine/wiki/Efficiency]
> 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|https://github.com/ben-manes/caffeine/wiki/Benchmarks] 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
(v6.3.4#6332)
