Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 22 Jul 2015 14:54:05 +0000 (UTC)
From: "Benedict (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12846914.1437576338000.256905.1437576845107@Atlassian.JIRA>
In-Reply-To: <JIRA.12846914.1437576338000@Atlassian.JIRA>
References: <JIRA.12846914.1437576338000@Atlassian.JIRA>
 <JIRA.12846914.1437576338270@arcas>
Subject: [jira] [Commented] (CASSANDRA-9864) Stress leaves threads running
 after a fatal error
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Benedict commented on CASSANDRA-9864:
-------------------------------------

Well, there isn't actually a good reason for it not to die here. So I wonder what non-daemon threads are running keeping the process up. It hasn't spun up any workers or anything by this point. Are the Java Driver's threads non-daemon?

However we can enforce it to sysexit in the event of any exception in the main thread quite easily.

> Stress leaves threads running after a fatal error
> -------------------------------------------------
>
>                 Key: CASSANDRA-9864
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9864
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>            Reporter: Ryan McGuire
>
> For some types of error, cassandra-stress is staying alive even after it shows an exception, and it will hang forever.
> Here's an example:
> {code}
> [10.200.241.112] All nodes available!
> INFO:benchmark:Started cassandra on 3 nodes with git SHA: efaff1bff92fdf4cc84007a5cc1e641ebf889633
> INFO:stress_compare:Running stress operation : user profile=https://dl.dropboxusercontent.com/u/15683245/8894_tiny.yaml  ops\(insert=1,\) n=1M -rate threads=3.
> INFO:benchmark:Running stress from '/home/ryan/fab/stress/default/tools/bin/cassandra-stress' : user profile=https://dl.dropboxusercontent.com/u/15683245/8894a
> INFO  23:50:05 Did not find Netty's native epoll transport in the classpath, defaulting to NIO.
> Exception in thread "main" java.lang.RuntimeException: java.lang.IllegalArgumentException: clustering_key
>         at org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:198)
>         at org.apache.cassandra.stress.StressProfile.maybeCreateSchema(StressProfile.java:162)
>         at org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:207)
>         at org.apache.cassandra.stress.StressAction.run(StressAction.java:55)
>         at org.apache.cassandra.stress.Stress.main(Stress.java:114)
> Caused by: java.lang.IllegalArgumentException: clustering_key
>         at com.datastax.driver.core.ColumnMetadata$Raw$Kind.fromStringV3(ColumnMetadata.java:235)
>         at com.datastax.driver.core.ColumnMetadata$Raw.fromRow(ColumnMetadata.java:263)
>         at com.datastax.driver.core.SchemaParser.groupByKeyspaceAndCf(SchemaParser.java:408)
>         at com.datastax.driver.core.SchemaParser$2.refresh(SchemaParser.java:246)
>         at com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:323)
>         at com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:264)
>         at com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:187)
>         at com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:75)
>         at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1265)
>         at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:337)
>         at org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:121)
>         at org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:189)
>         ... 4 more
> {code}
> So I'd love for that bug to go away, but in general, the stress process should exit when it encounters a fatal error.


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