cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Kjellman (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13291) Replace usages of MessageDigest with Guava's Hasher
Date Wed, 18 Oct 2017 20:30:01 GMT


Michael Kjellman commented on CASSANDRA-13291:

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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message