Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 6 Nov 2015 22:18:11 +0000 (UTC)
From: "Arunsandu (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12911179.1446837968000.3844.1446848291101@Atlassian.JIRA>
In-Reply-To: <JIRA.12911179.1446837968000@Atlassian.JIRA>
References: <JIRA.12911179.1446837968000@Atlassian.JIRA>
 <JIRA.12911179.1446837968083@arcas>
Subject: [jira] [Commented] (CASSANDRA-10670) Stress tool isn't working with
 tables not having non-primary keys
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Arunsandu commented on CASSANDRA-10670:
---------------------------------------

Jake, I see CASSANDRA-7739 issue in OPEN state. Is the work still going on to fix this issue? If so, can I please know the time frame for the fix?

> Stress tool isn't working with tables not having non-primary keys
> -----------------------------------------------------------------
>
>                 Key: CASSANDRA-10670
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10670
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Testing, Tools
>            Reporter: Arunsandu
>              Labels: performance, test
>             Fix For: 2.1.8, 2.2.2
>
>         Attachments: Error.jpg, request_trace.yaml
>
>   Original Estimate: 226h
>  Remaining Estimate: 226h
>
> Hi,
> I am trying to pass request_trace.yaml as an input to the stress-tool as below:
> ./cassandra-stress user profile=request_trace.yaml n=1000000 ops(likelyquery0=1,likelyquery1=2,insert=1) -node 10.32.100.16
> the script is perfectly working fine for the other tables. But I get the below error for request_trace table. Please check the request_trace.yaml file for the script. 
> This stress tool command throws error only when the table has single partition key as described above. In all the other cases where the table has non primary keys, am able to run the command and get the results.
>  ```
> ------------------------------------- request_trace.yaml---------------------------------------------------------
> DML ### THIS IS UNDER CONSTRUCTION!!!
> Keyspace Name
> keyspace: autogeneratedtest
> The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
> Table name
> table: request_trace
> The CQL for creating a table you wish to stress (optional if it already exists)
> table_definition:
> CREATE TABLE request_trace (
> service_context_id text,
> trace_statement text,
> PRIMARY KEY (service_context_id, trace_statement)
> )
> Column Distribution Specifications
> columnspec:
>     name: service_context_id
>     size: gaussian(10..20)
>     population: gaussian(300..500)
>     name: trace_statement
>     size: gaussian(5..15)
>     population: gaussian(800..1000)
> Batch Ratio Distribution Specifications
> insert:
> partitions: fixed(1) # Our partition key is the domain so only insert one per batch
> select: fixed(1)/1000 # We have 1000 posts per domain so 1/1000 will allow 1 post per batch
> batchtype: UNLOGGED # Unlogged batches
> A list of queries you wish to run against the schema
> #
> queries:
> likelyquery0:
> cql: SELECT * FROM request_trace WHERE service_context_id = ?
> fields: samerow
> likelyquery1:
> cql: SELECT * FROM request_trace WHERE service_context_id = ? AND trace_statement = ?
> fields: samerow
>  ```
>  ```
> ERROR:
> Warming up likelyquery0 with 50000 iterations...
> Warming up likelyquery1 with 50000 iterations...
> Warming up insert with 50000 iterations...
> Generating batches with [1..1] partitions and [0..0] rows (of [1..1] total rows in the partitions)
> Exception in thread "main" com.datastax.driver.core.exceptions.SyntaxError: line 1:28 no viable alternative at input 'WHERE' (UPDATE "request_trace" SET  [WHERE]...)
>     at com.datastax.driver.core.exceptions.SyntaxError.copy(SyntaxError.java:35)
>     at com.datastax.driver.core.DefaultResultSetFuture.extractCauseFromExecutionException(DefaultResultSetFuture.java:271)
>     at com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:82)
>     at org.apache.cassandra.stress.util.JavaDriverClient.prepare(JavaDriverClient.java:84)
>     at org.apache.cassandra.stress.StressProfile.getInsert(StressProfile.java:396)
>     at org.apache.cassandra.stress.settings.SettingsCommandUser$1.get(SettingsCommandUser.java:82)
>     at org.apache.cassandra.stress.settings.SettingsCommandUser$1.get(SettingsCommandUser.java:78)
>     at org.apache.cassandra.stress.operations.SampledOpDistributionFactory$1.get(SampledOpDistributionFactory.java:80)
>     at org.apache.cassandra.stress.StressAction$Consumer.<init>(StressAction.java:269)
>     at org.apache.cassandra.stress.StressAction.run(StressAction.java:204)
>     at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:105)
>     at org.apache.cassandra.stress.StressAction.run(StressAction.java:61)
>     at org.apache.cassandra.stress.Stress.main(Stress.java:114)
> Caused by: com.datastax.driver.core.exceptions.SyntaxError: line 1:28 no viable alternative at input 'WHERE' (UPDATE "request_trace" SET  [WHERE]...)
>     at com.datastax.driver.core.Responses$Error.asException(Responses.java:123)
>     at com.datastax.driver.core.SessionManager$1.apply(SessionManager.java:167)
>     at com.datastax.driver.core.SessionManager$1.apply(SessionManager.java:142)
>     at com.google.common.util.concurrent.Futures$1.apply(Futures.java:713)
>     at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:861)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>     at java.lang.Thread.run(Thread.java:745)
>  ```


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