[
https://issues.apache.org/jira/browse/CASSANDRA-13291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15923129#comment-15923129
]
Michael Kjellman commented on CASSANDRA-13291:
----------------------------------------------
Thanks Robert!
I've pushed up the changes to
https://github.com/mkjellman/cassandra/commit/71a33e37f87e82986927c6c929d0e32c2f54fbf4
(https://github.com/mkjellman/cassandra/tree/CASSANDRA-13291)
* Good catch on {{assertNotSame}} ... but there isn't actually
{{assertNotEquals}}... Looks like I need to do {{Assert.assertFalse}}
* I had also thought about offline tools... but, I put
{{MessagingService.CURRENT_HASH_FUNCTION}} in {{MessagingService}} because of
the logic like MessagingService.instance().areAllNodesAtLeast21() to migrate
the digest used during upgrade. So, I figured eventually the "current" one
would need to live in there anyways... It looks like we don't have this in
trunk anymore because maybe we don't have anything to migrate anymore? I feel
like FBUtilities isn't a great place because at some point we need to have it
versioned.. thoughts?
* I used {{JCAUtil}} because that is what the JDK was doing internally..... I
figured it was optimized in some way which is why the JDK was doing it that
way... I'll just do it manually for now as [~jasobrown] didn't like it either.
> 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)
