cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
Date Wed, 12 Oct 2011 13:35:12 GMT

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

Sylvain Lebresne commented on CASSANDRA-1034:
---------------------------------------------

bq. But the whole point of the ticket is to remove this concept. Are you saying that can't
be guaranteed?

There is a misunderstanding. The whole point of this ticket is to *enforce* this concept.
A token is a range, a segment on the ring, there is nothing we can do about it. It's like
saying the point of the ticket is to remove the concept that a segment is different from a
point.

I'm happy to discuss that, and that is clearly where we should start, but I'm pretty sure
that the *problem* we want to fix is that the current code is pretending than a segment is
equal to a point. The current code is pretending that a token t is the same thing than a key
having this token. This only work if there is only one key have a given token, otherwise it's
buggy, you identify all keys having the same token as equal, that is the problem.

And saying that you'll change the comparison of DK to include the key and pretending that
a token is the same thing that some fictive key that as far as key comparison is concerned
would be before any key having the token (which is *exactly* what Pavel's patch is doing)
doesn't work either. As I've said earlier with examples.

I'm saying that the right way to fix is to make the code treats Token as a segment (because
you know, that's what it is) and a key as a point. Now that, imho, is not of a debatable nature:
it's either true or false (and imho clearly true but maybe i'm completely stupid). But at
the very least we should agree on that first, even before thinking about how we will code
it.

Then, once we agree on the problem, there is the question of how we do it. And then, my second
argument is that shoving a token (a segment) and a (decorated) key (a point) into the same
class (that we would happen to call Token) is, why probably "possible", likely an error-prone,
confusing and frankly ugly idea. You can create a class representing both a segment and point,
having it work correctly underneath and write code using that, but it will unlikely be beautiful
nor easy to use. But it's "possible". 
                
> 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: Pavel Yaskevich
>            Priority: Minor
>             Fix For: 1.1
>
>         Attachments: 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, 0002-LengthPartitioner.patch,
1034-1-Generify-AbstractBounds-v3.patch, 1034-2-Remove-assumption-that-token-and-keys-are-one-to-one-v3.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

        

Mime
View raw message