[
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)
