[
https://issues.apache.org/jira/browse/CASSANDRA-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795726#action_12795726
]
Jonathan Ellis edited comment on CASSANDRA-658 at 1/1/10 2:23 AM:
------------------------------------------------------------------
this actually has a race for simple columns: if a value is preset for a given
column name, and two threads (A and B) run the putIfAbsent part at the same
time, then A goes into the synchronized block and changes the value, thread C
could attempt addColumn and sync on the value put by A, while B syncs on the
old value.
This should be fixable by using replace(), not put().
was (Author: jbellis):
this actually has a race for simple columns: if a value is preset for a
given column name, and two threads (A and B) run the putIfAbsent part at the
same time, then A goes into the synchronized block and changes the value,
thread C could attempt addColumn and sync on the value put by A, while B syncs
on the old value.
> Hinted Handoff CF contention
> ----------------------------
>
> Key: CASSANDRA-658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-658
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.5
> Environment: debian lenny amd64 OpenJDK 64-Bit Server VM (build
> 1.6.0_0-b11, mixed mode)
> Reporter: Brandon Williams
> Assignee: Jonathan Ellis
> Fix For: 0.9
>
> Attachments:
> 0001-use-throughput-and-op-count-instead-of-size-and-column.txt,
> 0002-replace-sharded-row-locks-with-column-level-locking.txt,
> 0003-remove-atomic-size-from-sc.txt
>
>
> Hinted handoff causes a lot of contention on the HH CF, causing insert speed
> to massively drop. Most of the row mutation stage threads end up blocking on
> each other at Memtable.resolve. This is because HH sends the hint to the
> closest node, which will always be the node handling the write.
> To reproduce: start a cluster with even InitialTokens, and begin a constant
> stream of writes to one node, with an even key distribution. (I used 4 nodes
> and stress.py in random mode.) Take a node down, and the insert rate begin
> to drop, eventually settling between 100-300/s and sustaining there.
> Bringing the down node back up will restore the original insert rate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
