cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Mon, 27 Jan 2014 04:57:41 GMT

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

Jonathan Ellis commented on CASSANDRA-5549:
-------------------------------------------

Okay, went with plan B of unifying MT/Pool and MO/Allocator.  Pretty happy with how this worked
out: https://github.com/jbellis/cassandra/commits/5549-3

In my mind, off heap stuff can now be added by creating an appropriate Allocator class, and
a Pool implementation that owns two sub-pools.

(I'm seeing a bunch of test failures but I don't think it's from this refactor.)

> 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