cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
Date Wed, 12 Oct 2011 11:15:12 GMT


Pavel Yaskevich commented on CASSANDRA-1034:

Can you please define what do you mean by "pure token"? Aren't we supposed to generate token
from key in all situations except initial token in config and middle point between tokens?
So if you do a range slice using tokens instead of keys TokenFactory.fromString will force
you to use correctly serialized token data which will also include key.

bq. It's error-prone and make coding more complicated. We're merging object that are not the
same thing etc...

If token is generated from key than for me it's natural to have a key as member. The thing
is that you are enable to create a "pure" token, Partitioner will always give you a Token
with valid key except for midpoint method so if partitioner is used to generate tokens you
are guaranteed to have a valid key in the resulting token instance.

bq. It's a ~300K patch. Sure it's mostly simple changes, but it's still that many changes
that could introduce a typo somewhere that causes a bug.

The same thing I can say about your set of patches - it's 198 KB. Aren't we writing tests
to catch such bugs?
> Remove assumption that Key to Token is one-to-one
> -------------------------------------------------
>                 Key: CASSANDRA-1034
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message