[
https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863148#comment-13863148
]
Benedict commented on CASSANDRA-5549:
-------------------------------------
Largely the same as before, the mutation thread blocks until enough memory
becomes available to complete the request. The difference is, depending on
where/why the breach occurs, it may not block until after it completes its
modification (as some of the memory bookkeeping is batched to the end for ease
and speed).
Any call to MemoryOwner.allocate() is potentially a blocking call, if there
isn't enough room available to satisfy the allocation.
> 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)
