cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Knighton (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11517) o.a.c.utils.UUIDGen could handle contention better
Date Fri, 06 May 2016 06:16:12 GMT


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.


CI looks good relative to upstream. If you're fine with the test changes [~aweisberg], this

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|].

> o.a.c.utils.UUIDGen could handle contention better
> --------------------------------------------------
>                 Key: CASSANDRA-11517
>                 URL:
>             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
> 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

View raw message