cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Smith (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6106) QueryState.getTimestamp() & FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000
Date Thu, 13 Mar 2014 23:29:48 GMT

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

Christopher Smith commented on CASSANDRA-6106:
----------------------------------------------

Apologies. I dropped the ball and never got back to this. Thanks for pinging me again.

Obviously, this is non-trivial, or it'd already have been done. However non-trivial != impossible.

The way to do this would be reading the data directly from the gtod structure (actually vdso_vsyscall_gtod_data:
http://lxr.linux.no/linux+v3.13.5/arch/x86/include/asm/vgtod.h#L7). There are a bunch of caveats
(for one, you'd need to have a fallback strategy if there was no VDSO for the particular architecture
you are on), but you could in theory have some JNI code that grabbed the addresses of gtod.wall_time_sec
and gtod.wall_time_nsec and then made them visible as direct ByteBuffer's through the NewDirectByteBuffer
function. You could then access the memory much like is done in do_realtime (http://lxr.linux.no/linux/arch/x86/vdso/vclock_gettime.c#L173).
I imagine you'd need some extra logic in Java space to handle endian issues, and you'd need
to make sure you created a memory barrier every time you entered and exited the Java function
to read it, but I think that all is doable.

There might be an even nicer way to do this with JNA, but I've not used it, so I'll leave
that to other to others to figure out.

> QueryState.getTimestamp() & FBUtilities.timestampMicros() reads current timestamp
with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6106
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6106
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: DSE Cassandra 3.1, but also HEAD
>            Reporter: Christopher Smith
>            Priority: Minor
>              Labels: timestamps
>             Fix For: 2.1 beta2
>
>         Attachments: microtimstamp.patch, microtimstamp_random.patch, microtimstamp_random_rev2.patch
>
>
> I noticed this blog post: http://aphyr.com/posts/294-call-me-maybe-cassandra mentioned
issues with millisecond rounding in timestamps and was able to reproduce the issue. If I specify
a timestamp in a mutating query, I get microsecond precision, but if I don't, I get timestamps
rounded to the nearest millisecond, at least for my first query on a given connection, which
substantially increases the possibilities of collision.
> I believe I found the offending code, though I am by no means sure this is comprehensive.
I think we probably need a fairly comprehensive replacement of all uses of System.currentTimeMillis()
with System.nanoTime().



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message