cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-5001) Generated time-based UUID don't conform to the spec
Date Wed, 28 Nov 2012 17:45:00 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-5001:
----------------------------------------

    Attachment: 5001.txt
    
> Generated time-based UUID don't conform to the spec
> ---------------------------------------------------
>
>                 Key: CASSANDRA-5001
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5001
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2.0
>
>         Attachments: 5001.txt
>
>
> When UUIDGen layout the clock sequence and and node part of version 1 UUID, it does so
with
> {noformat}
> private long getClockSeqAndNode(InetAddress addr)
> {
>     long lsb = 0;
>     lsb |= (clock & 0x3f00000000000000L) >>> 56; // was 58?
>     lsb |= 0x0000000000000080;
>     lsb |= (clock & 0x00ff000000000000L) >>> 48;
>     lsb |= makeNode(addr);
>     return lsb;
> }
> {noformat}
> This is not correct however, as this layout the clock seq (and variant) on the right-most
part of the lsb while it should be on the left-most one.
> At a minimum, the generated UUID don't fully respect the spec since the variant is not
set correctly. But it also means that the clock seq bits end up being all 0's (as can be trivially
seen in the string representation of the generated UUIDs).
> Note that none of those is a huge huge deal as there is still largely enough random bytes
to ensure that two different nodes won't end up with the same lsb. And having the variant
wrong has probably no practical implementation. There is no reason not to fix those though.
> One other small details is that the getAdjustedTimestamp as a sign error so that it returns
completely broken timestamps. That being said the method is currently unused so that's not
a big deal. I'm attaching a fix for that part too because that method might be useful someday
but I won't shed a tear if we prefer just removing it.
> I'm marking this for 1.2 because I'm not sure it's worth bothering with 1.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message