[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-1034:
----------------------------------------
Attachment: 0003-unit-test.patch
0002-Remove-assumption-that-token-and-keys-are-one-to-one.patch
0001-Generify-AbstractBounds.patch
Attaching rebased patch (against trunk).
I've slightly refactored the patches too. The first contains only the
generification of AbstractBounds. It's obviously a bit "dumb" taken alone since
it generify but doesn't allow anything else than tokens. The only other
noticeable thing is the removal of the Range.compare() method (in favor of the
compareTo method of Token). I have no idea what that method was about in the
first place. The second patch does the rest of the work and has got some minor
cleanups. I've also tried to add some new comments to make it more digestible.
I also include a third patch with a small unit test.
Having spend quite some time thinking about this issue, I do think that this is
a good way to fix it, the alternative of allowing to mixing Token and
DecoratedKey directly in a Range being (to have pursued it a bit before giving
up) much more messy and error prone imho. Now I can't force anyone to like this
solution but I also won't rebase this forever.
> Remove assumption that Key to Token is one-to-one
> -------------------------------------------------
>
> Key: CASSANDRA-1034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1034
> Project: Cassandra
> Issue Type: Bug
> Reporter: Stu Hood
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.1
>
> Attachments: 0001-Generify-AbstractBounds.patch,
> 0002-Remove-assumption-that-token-and-keys-are-one-to-one.patch,
> 0003-unit-test.patch, 1034_v1.txt, CASSANDRA-1034.patch
>
>
> get_range_slices assumes that Tokens do not collide and converts a KeyRange
> to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and
> would lead to a very weird heisenberg.
> Converting AbstractBounds to use a DecoratedKey would solve this, because the
> byte[] key portion of the DecoratedKey can act as a tiebreaker.
> Alternatively, we could make DecoratedKey extend Token, and then use
> DecoratedKeys in places where collisions are unacceptable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
