cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Wed, 08 May 2013 05:05:15 GMT


Jonathan Ellis commented on CASSANDRA-5549:

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

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:
>             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:

View raw message