[jira] [Updated] (CASSANDRA-5001) Generated time-based UUID don't conform to the spec

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

     [ 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