Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 28 Jan 2016 22:42:39 +0000 (UTC)
From: "T Jake Luciani (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12916618.1448625411000.243402.1454020959942@Atlassian.JIRA>
In-Reply-To: <JIRA.12916618.1448625411000@Atlassian.JIRA>
References: <JIRA.12916618.1448625411000@Atlassian.JIRA>
 <JIRA.12916618.1448625411642@arcas>
Subject: [jira] [Commented] (CASSANDRA-10779) Mutations do not block for
 completion under view lock contention
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

T Jake Luciani commented on CASSANDRA-10779:
--------------------------------------------

I ran highly contended mvbench runs with 3.0 branch, Tyler's v2 branch and Carl's completable future test.  

Both thobbs and carls fixes the timeout issue, but when I add a stress write workload running along side the view benchmark Tylers branch causes stress to timeout because the write stage is blocked waiting on the contended locks. In Carl's version this doesn't happen since the mutations are put back on the queue freeing threads to work on other things. So I think we should go with Carl's version.

In the case of an uncontended mvbench run (no lock contention) there is no difference in performance between the current 3.0 branch and Carl's branch.

In the highly contended case as we are now waiting before acking the write the performance has dropped to be 50% worse than non-mv.  However I think we can fix this by improving lock contention CASSANDRA-10307


> Mutations do not block for completion under view lock contention
> ----------------------------------------------------------------
>
>                 Key: CASSANDRA-10779
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10779
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths
>         Environment: Windows 7 64-bit, Cassandra v3.0.0, Java 1.8u60
>            Reporter: Will Zhang
>            Assignee: Tyler Hobbs
>             Fix For: 3.0.x, 3.x
>
>
> Hi guys,
> I encountered the following warning message when I was testing to upgrade from v2.2.2 to v3.0.0. 
> It looks like a write time-out but in an uncaught exception. Could this be an easy fix?
> Log file section below. Thank you!
> {code}
> 	WARN  [SharedPool-Worker-64] 2015-11-26 14:04:24,678 AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread Thread[SharedPool-Worker-64,10,main]: {}
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out - received only 0 responses.
> 		at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:427) ~[apache-cassandra-3.0.0.jar:3.0.0]
> 		at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:386) ~[apache-cassandra-3.0.0.jar:3.0.0]
> 		at org.apache.cassandra.db.Mutation.apply(Mutation.java:205) ~[apache-cassandra-3.0.0.jar:3.0.0]
> 		at org.apache.cassandra.db.Keyspace.lambda$apply$59(Keyspace.java:435) ~[apache-cassandra-3.0.0.jar:3.0.0]
> 		at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_60]
> 		at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) ~[apache-cassandra-3.0.0.jar:3.0.0]
> 		at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-3.0.0.jar:3.0.0]
> 		at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> 	INFO  [IndexSummaryManager:1] 2015-11-26 14:41:10,527 IndexSummaryManager.java:257 - Redistributing index summaries
> {code}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)