cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Thu, 30 Jan 2014 01:11:10 GMT


Benedict commented on CASSANDRA-5549:

I've rebased from trunk and fixed the bugs and pushed (-f) to [merge-5549|].
There were two small issues: in RangeTombstoneList I was setting start[i] = null before I
copied its value; and in FBUtilities.hashToBigInteger() my "equivalency" rewrite wasn't so
equivalent after all, so I reverted it. Whoops.

There are still three new tests failing, but this is because we fixed a bug and so DefsTest
no longer times out; CASSANDRA-6636 addresses these new issues.

> Remove Table.switchLock
> -----------------------
>                 Key: CASSANDRA-5549
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Benedict
>              Labels: performance
>             Fix For: 2.1
>         Attachments: 5549-removed-switchlock.png, 5549-sunnyvale.png
> As discussed in CASSANDRA-5422, Table.switchLock is a bottleneck on the write path. 
ReentrantReadWriteLock is not lightweight, even if there is no contention per se between readers
and writers of the lock (in Cassandra, memtable updates and switches).

This message was sent by Atlassian JIRA

View raw message