[
https://issues.apache.org/jira/browse/CASSANDRA-13291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15929784#comment-15929784
]
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 {{org.apache.cassandra.tools}} 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. WDYT?
{{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: https://issues.apache.org/jira/browse/CASSANDRA-13291
> 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
(v6.3.15#6346)
