cassandra-commits mailing list archives

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


Sam Tunnicliffe commented on CASSANDRA-13291:

This breaks stuff in schema updates when RP is used (not sure how well that's going to be
covered by utest/dtest). To repro, just create a 2 node ccm cluster with RP, the second node
will error out trying to update schema in {{StorageService::prepareToJoin}}.
I didn't have time to dig into it, but I guess the schema digest calculation is at fault,
M3P isn't affected.

Now, back to that horse I was flogging...

If we've decided that the threadlocal stuff is no longer necessary, I'm not sure why you moved
it from {{FBUtilities}} to {{MD5Digest}} and kept its use by {{ResultSet}} and {{GuidGenerator}}.
If we're sure we don't need it anymore, lets get rid of it completely. Otherwise, I think
it would make sense for {{RandomPartitioner::hashToBigInteger}} to make use of it, given its

The main reason I'm interesting is that earlier this week I came across CASSANDRA-13964, which
obviously overlaps with this somewhat.

> 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