[ 
https://issues.apache.org/jira/browse/CASSANDRA-13291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209259#comment-16209259
 ] 

Jason Brown commented on CASSANDRA-13291:
-----------------------------------------

[~beobal] Hmm, you are correct, and I can repro easily. With a two node ccm 
cluster, I got this error in node1:

{noformat}
org.apache.cassandra.exceptions.ConfigurationException: Token must be >= 0 and 
<= 2**127
        at 
org.apache.cassandra.dht.RandomPartitioner$2.validate(RandomPartitioner.java:160)
 ~[main/:na]
        at 
org.apache.cassandra.config.DatabaseDescriptor.applyInitialTokens(DatabaseDescriptor.java:927)
 ~[main/:na]
        at 
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:317)
 ~[main/:na]
        at 
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:141)
 ~[main/:na]
        at 
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:602)
 [main/:na]
        at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537) 
[main/:na]
        at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:646) 
[main/:na]
{noformat}

And this error in node2, which got a bit further in the boot sequence:

{noformat}
ERROR [main] 2017-10-18 05:37:18,547 CassandraDaemon.java:663 - Exception 
encountered during startup
org.apache.cassandra.exceptions.InvalidRequestException: Key may not be empty
        at 
org.apache.cassandra.cql3.QueryProcessor.validateKey(QueryProcessor.java:186) 
~[main/:na]
        at 
org.apache.cassandra.cql3.statements.ModificationStatement.buildPartitionKeyNames(ModificationStatement.java:310)
 ~[main/:na]
        at 
org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:656)
 ~[main/:na]
        at 
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:644)
 ~[main/:na]
        at 
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:595)
 ~[main/:na]
        at 
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:590)
 ~[main/:na]
        at 
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:296)
 ~[main/:na]
        at 
org.apache.cassandra.db.SystemKeyspace.updateSchemaVersion(SystemKeyspace.java:648)
 ~[main/:na]
        at org.apache.cassandra.schema.Schema.updateVersion(Schema.java:533) 
~[main/:na]
        at 
org.apache.cassandra.schema.Schema.updateVersionAndAnnounce(Schema.java:541) 
~[main/:na]
        at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:787)
 ~[main/:na]
        at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:622) 
~[main/:na]
        at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:569) 
~[main/:na]
        at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:364) 
[main/:na]
        at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:557) 
[main/:na]
        at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:646) 
[main/:na]
{noformat}

> 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

Reply via email to