[
https://issues.apache.org/jira/browse/CASSANDRA-11517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15273683#comment-15273683
]
Joel Knighton commented on CASSANDRA-11517:
-------------------------------------------
Implementation after Sylvain's points looks good to me. The test problem with
lastTimestamp never being updated didn't seem to be fixed - lastTimestamp was
always zero, so we were testing only that the timestamp of a UUID was greater
than 0. I've updated the test to fix this such that the condition asserts that
UUID timestamps are strictly increasing within each test thread. I also
slightly decreased the test iterations (runtime was reaching 6s on my dev
machines, which seemed a bit long), rebased on master, and pushed for updated
CI.
||branch||testall||dtest||
|[CASSANDRA-11517-trunk|https://github.com/jkni/cassandra/tree/CASSANDRA-11517-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-CASSANDRA-11517-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-CASSANDRA-11517-trunk-dtest]|
CI looks good relative to upstream. If you're fine with the test changes
[~aweisberg], this LGTM.
Side note: out of curiosity, I wrote a small JMH benchmark and ran it on
Windows, Linux, and FreeBSD. It confirmed a throughput increase on all
platforms. That test is available here and could be added as a microbenchmark:
[CASSANDRA-11517-trunk-jmh|https://github.com/jkni/cassandra/tree/CASSANDRA-11517-trunk-jmh].
> o.a.c.utils.UUIDGen could handle contention better
> --------------------------------------------------
>
> Key: CASSANDRA-11517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11517
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Priority: Minor
> Fix For: 3.x
>
>
> I noticed this profiling a query handler implementation that uses UUIDGen to
> get handles to track queries for logging purposes.
> Under contention threads are being unscheduled instead of spinning until the
> lock is available. I would have expected intrinsic locks to be able to adapt
> to this based on profiling information.
> Either way it's seems pretty straightforward to rewrite this to use a CAS
> loop and test that it generally produces unique values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
