cassandra-commits mailing list archives

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

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

Benedict commented on CASSANDRA-5549:
-------------------------------------

I've rebased from trunk and fixed the bugs and pushed (-f) to [merge-5549|https://github.com/belliottsmith/cassandra/tree/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: https://issues.apache.org/jira/browse/CASSANDRA-5549
>             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
(v6.1.5#6160)

Mime
View raw message