cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13291) Replace usages of MessageDigest with Guava's Hasher
Date Fri, 17 Mar 2017 11:29:41 GMT


Robert Stupp commented on CASSANDRA-13291:

bq. MessagingService.instance().areAllNodesAtLeast21()
We don’t have that method in trunk ;) But I still think that {{MessagingService}} is not
a good place for {{CURRENT_HASH_FUNCTION}}, because {{MessagingService}} may start up everything
in an uncontrolled way, even if the tests in {{}} pass (it’s difficult
to test all code paths in the offline tools from a unit test). {{SchemaConstants}} was introduced
to break some circular class dependencies, that “magically” started some stuff - i.e.
referencing {{MessagingService}} there is not good.
I wouldn’t mind to introduce a new class for “current hash function” though. {{SchemaConstants.emptyVersion}}
could be moved there, too. (FBUtilities is probably a bad place, yea.)

{{RandomPartitioner}} seems to be one of the two users of {{FBUtilities.threadLocalMD5Digest}}
via some {{GuidGenerator}}. We could move {{GuidGenerator}} into {{RandomPartitioner}} -
no other class uses it and with that change, it becomes clear that it’s only there for RP.

{{MD5Digest}} - I think that class is ok-ish. Removing it would result in a ton of code changes.
However, moving {{FBUtilities.threadLocalMD5Digest}} into {{MD5Digest}} feels ok - especially
considering the previous point. WDYT?

> Replace usages of MessageDigest with Guava's Hasher
> ---------------------------------------------------
>                 Key: CASSANDRA-13291
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Michael Kjellman
>            Assignee: Michael Kjellman
>         Attachments: CASSANDRA-13291-trunk.diff
> During my profiling of C* I frequently see lots of aggregate time across threads being
spent inside the MD5 MessageDigest implementation. Given that there are tons of modern alternative
hashing functions better than MD5 available -- both in terms of providing better collision
resistance and actual computational speed -- I wanted to switch out our usage of MD5 for alternatives
(like adler128 or murmur3_128) and test for performance improvements.
> Unfortunately, I found given the fact we use MessageDigest everywhere --  switching out
the hashing function to something like adler128 or murmur3_128 (for example) -- which don't
ship with the JDK --  wasn't straight forward.
> The goal of this ticket is to propose switching out usages of MessageDigest directly
in favor of Hasher from Guava. This means going forward we can change a single line of code
to switch the hashing algorithm being used (assuming there is an implementation in Guava).

This message was sent by Atlassian JIRA

View raw message