[jira] [Comment Edited] (CASSANDRA-5549) Remove Table.switchLock

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis edited comment on CASSANDRA-5549 at 5/8/13 5:05 AM:
-------------------------------------------------------------------

Rebased my switchLock-removal patch from CASSANDRA-5064 to https://github.com/jbellis/cassandra/commits/5549.

Sylvain's comments from then:

# I see nothing that prevents flushing the same memtable multiple times.
# getting the commit log context and switching the memtable is not done atomically with respect to writes. So a write can be pushed in the commit log after the context we're getting but still reach the memtable we're about to flush. For normal update, this is mostly inefficient in that we'll kept commit logs around long than necessary and potentially replay some update unnecessarily, but for counter this is a bug.
# it's also possible that for postFlush tasks to not be scheduled in the order the commit log context were acquired. So we could discard a commitlog for which the data is not yet fully flushed.

I haven't yet addressed these concerns; it's just a straight-up rebase so far.  However, unit tests pass, so it's probably Good Enough to see what kind of performance impact this would have. /cc [~danielnorberg]
                
      was (Author: jbellis):
    Rebased my switchLock-removal patch from CASSANDRA-5064.

Sylvain's comments from then:

# I see nothing that prevents flushing the same memtable multiple times.
# getting the commit log context and switching the memtable is not done atomically with respect to writes. So a write can be pushed in the commit log after the context we're getting but still reach the memtable we're about to flush. For normal update, this is mostly inefficient in that we'll kept commit logs around long than necessary and potentially replay some update unnecessarily, but for counter this is a bug.
# it's also possible that for postFlush tasks to not be scheduled in the order the commit log context were acquired. So we could discard a commitlog for which the data is not yet fully flushed.

I haven't yet addressed these concerns; it's just a straight-up rebase so far.  However, unit tests pass, so it's probably Good Enough to see what kind of performance impact this would have. /cc [~danielnorberg]
                  
> Remove Table.switchLock
> -----------------------
>
>                 Key: CASSANDRA-5549
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5549
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>             Fix For: 2.0
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira