[
https://issues.apache.org/jira/browse/CASSANDRA-13291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209970#comment-16209970
]
Michael Kjellman edited comment on CASSANDRA-13291 at 10/18/17 8:31 PM:
------------------------------------------------------------------------
Alright, after chatting a bit with Sam and Jason I've pushed up a new squashed
commit that reverts the MD5 hasher usage in {{RandomPartitioner}} and
{{GuidGenerator}} back to the thread local (and added a comment). Additionally,
I pulled in the change Sam has for CASSANDRA-13964 that adds an additional MD5
MessageDigest thread local to the {{RandomPartitioner}} class itself.
# In the interest of "if it's not broke, don't fix it", leaving the two direct
usages of MessageDigest (as my first iterations of this change did) (via a
thread local) for {{RandomPartioner}} feels like the most sane thing to do as
RandomPartitioner will never not be MD5 and it's very difficult to quantify how
behavior and performance might change when switching to Guava's Hasher for this
use case
# Functionally, this means the original intent of this ticket can still be
fully realized, which is to set the foundation for ultimately changing the
usage of MD5 digests in the rest of the codebase to another hashing function
with minimal LoC required to implement that in the near future
was (Author: mkjellman):
Alright, after chatting a bit with Sam and Jason I've pushed up a new squashed
commit that reverts the MD5 hasher usage in {{RandomPartitioner}} and
{{GuidGenerator}} back to the thread local (and added a comment). Additionally,
I pulled in the change Sam has for 13964 that adds an additional MD5
MessageDigest thread local to the {{RandomPartitioner}} class itself.
# In the interest of "if it's not broke, don't fix it", leaving the two direct
usages of MessageDigest (as my first iterations of this change did) (via a
thread local) for {{RandomPartioner}} feels like the most sane thing to do as
RandomPartitioner will never not be MD5 and it's very difficult to quantify how
behavior and performance might change when switching to Guava's Hasher for this
use case
# Functionally, this means the original intent of this ticket can still be
fully realized, which is to set the foundation for ultimately changing the
usage of MD5 digests in the rest of the codebase to another hashing function
with minimal LoC required to implement that in the near future
> 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
