[ https://issues.apache.org/jira/browse/CASSANDRA-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543624#comment-14543624 ]
Jonathan Ellis commented on CASSANDRA-9381: ------------------------------------------- Is this a new regression? > AbstractColumnFamilyInputFormat is incorrectly interpreting token values when > building ColumnFamilySplit > -------------------------------------------------------------------------------------------------------- > > Key: CASSANDRA-9381 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9381 > Project: Cassandra > Issue Type: Bug > Components: Hadoop > Reporter: Mike Adamson > Fix For: 2.2.x > > > The SplitCallable.call method in AbstractColumnFamilyInputFormat has the > following code for building ColumnFamilySplits: > {noformat} > for (TokenRange subSplit : subSplits.keySet()) > { > List<TokenRange> ranges = subSplit.unwrap(); > for (TokenRange subrange : ranges) > { > ColumnFamilySplit split = > new ColumnFamilySplit( > > subrange.getStart().toString().substring(2), > subrange.getEnd().toString().substring(2), > subSplits.get(subSplit), > endpoints); > logger.debug("adding {}", split); > splits.add(split); > } > } > {noformat} > The subrange.getStart().toString().substring(2) works for the > OrderPreservingPartitioner because the toString for the OPPToken in the java > driver returns a hex value preceded by 0x. It doesn't work for the > Murmur3Partitioner because the toString for the M3PToken returns > Long.toString. > As a result the tokens lose their first 2 digits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)