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

Vijay commented on CASSANDRA-5001:
----------------------------------

+1

Nit: it might be nice to move the calculation in getClockSeqAndNode into 
makeNode so we can cache it in nodeCache.
                
> 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

Reply via email to