[
https://issues.apache.org/jira/browse/CASSANDRA-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-1954:
----------------------------------------
Attachment: 0001-Remove-flusherLock-readLock.patch
Attached patch implements what's hinted in my previous comment. Mainly it keeps
the flusher lock to unsure we discard commit log segment in the order we read
them, but remove the readLock on writes, so flush don't block writes anymore.
It passes unit test but that doesn't say much.
> Double-check or replace RRW memtable lock
> -----------------------------------------
>
> Key: CASSANDRA-1954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1954
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Priority: Minor
> Attachments:
> 0001-Double-check-in-maybeSwitchMemtable-to-minimize-writeL.txt,
> 0001-Remove-flusherLock-readLock.patch
>
>
> {quote}...when a Memtable reaches its threshold, up to (all) N write threads
> will often notice, and race to acquire the writeLock in order to freeze the
> memtable. This means that we do way more writeLock acquisitions than we need
> to...{quote}
> See CASSANDRA-1930 for backstory, but adding double checking inside a read
> lock before trying to re-entrantly acquire the writelock would eliminate most
> of these excess writelock acquisitions.
> Alternatively, we should explore removing locking from these structures
> entirely, and replacing the writeLock acquisition with a per-memtable counter
> of active threads.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
