[jira] [Commented] (CASSANDRA-4683) running nodetool cleanup throws an exception
[ https://issues.apache.org/jira/browse/CASSANDRA-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461439#comment-13461439 ] Bartłomiej Romański commented on CASSANDRA-4683: My logs shows that all my nodes are 1.1.5: br@c2:~$ sudo grep 'Cassandra version' /var/log/cassandra/system.log INFO [main] 2012-09-18 05:01:56,121 StorageService.java (line 423) Cassandra version: 1.1.5 running nodetool cleanup throws an exception Key: CASSANDRA-4683 URL: https://issues.apache.org/jira/browse/CASSANDRA-4683 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Bartłomiej Romański We've just upgraded to 1.1.5 from 1.1.2. After that running nodetool cleanup we've got the following error: Exception in thread main java.lang.AssertionError at org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:462) at org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:195) at org.apache.cassandra.utils.NodeId$LocalIds.clinit(NodeId.java:43) at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50) at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1447) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:89) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1292) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1380) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:812) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Any ideas? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4423) auto completion in cqlsh should work when using fully qualified name
[
https://issues.apache.org/jira/browse/CASSANDRA-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4423:
-
Attachment: CASSANDRA-4423.txt
auto completion in cqlsh should work when using fully qualified name
Key: CASSANDRA-4423
URL: https://issues.apache.org/jira/browse/CASSANDRA-4423
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jackson Chung
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6, 1.2.0
Attachments: CASSANDRA-4423.txt
minor cqlsh improvement:
the auto completion in cqlsh rocks, so this is just to make a nitpick
improvement:
if i type
{panel}
cqlsh create KEYSPACE test WITH strategy_class = 'SimpleStrategy' and
{panel}
then tab tab after it, it will auto complete into:
{panel}
cqlsh create KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor =
{panel}
but if i use a fully qualified name:
{panel}
cqlsh create KEYSPACE test WITH strategy_class =
'org.apache.cassandra.locator.SimpleStrategy' AND
strategy_option_name
{panel}
it is not smart enough to figured out the available options.
It'd be nice to make the auto completion works for those fully qualified
cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4423) auto completion in cqlsh should work when using fully qualified name
[
https://issues.apache.org/jira/browse/CASSANDRA-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4423:
-
Fix Version/s: 1.2.0
1.1.6
auto completion in cqlsh should work when using fully qualified name
Key: CASSANDRA-4423
URL: https://issues.apache.org/jira/browse/CASSANDRA-4423
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jackson Chung
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6, 1.2.0
Attachments: CASSANDRA-4423.txt
minor cqlsh improvement:
the auto completion in cqlsh rocks, so this is just to make a nitpick
improvement:
if i type
{panel}
cqlsh create KEYSPACE test WITH strategy_class = 'SimpleStrategy' and
{panel}
then tab tab after it, it will auto complete into:
{panel}
cqlsh create KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor =
{panel}
but if i use a fully qualified name:
{panel}
cqlsh create KEYSPACE test WITH strategy_class =
'org.apache.cassandra.locator.SimpleStrategy' AND
strategy_option_name
{panel}
it is not smart enough to figured out the available options.
It'd be nice to make the auto completion works for those fully qualified
cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4423) auto completion in cqlsh should work when using fully qualified name
[
https://issues.apache.org/jira/browse/CASSANDRA-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4423:
-
Labels: cqlsh (was: )
auto completion in cqlsh should work when using fully qualified name
Key: CASSANDRA-4423
URL: https://issues.apache.org/jira/browse/CASSANDRA-4423
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jackson Chung
Assignee: Aleksey Yeschenko
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6, 1.2.0
Attachments: CASSANDRA-4423.txt
minor cqlsh improvement:
the auto completion in cqlsh rocks, so this is just to make a nitpick
improvement:
if i type
{panel}
cqlsh create KEYSPACE test WITH strategy_class = 'SimpleStrategy' and
{panel}
then tab tab after it, it will auto complete into:
{panel}
cqlsh create KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor =
{panel}
but if i use a fully qualified name:
{panel}
cqlsh create KEYSPACE test WITH strategy_class =
'org.apache.cassandra.locator.SimpleStrategy' AND
strategy_option_name
{panel}
it is not smart enough to figured out the available options.
It'd be nice to make the auto completion works for those fully qualified
cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4706) CQL3 CREATE TABLE with set and counter causes java.lang.IllegalArgumentException
Jonathan Rudenberg created CASSANDRA-4706:
-
Summary: CQL3 CREATE TABLE with set and counter causes
java.lang.IllegalArgumentException
Key: CASSANDRA-4706
URL: https://issues.apache.org/jira/browse/CASSANDRA-4706
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Environment: rev 60bf68ca (tagged 1.2.0-beta1-tentative)
[cqlsh 2.2.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | Thrift
protocol 19.34.0]
OS X 10.8.2
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Ubuntu 12.04.1 LTS
java version 1.7.0_07
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Reporter: Jonathan Rudenberg
Priority: Blocker
Running a freshly compiled cassandra with non data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4706) CQL3 CREATE TABLE with set and counter causes java.lang.IllegalArgumentException
[
https://issues.apache.org/jira/browse/CASSANDRA-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Rudenberg updated CASSANDRA-4706:
--
Environment:
rev 60bf68ca (tagged 1.2.0-beta1-tentative)
cqlsh 2.2.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.34.0
OS X 10.8.2
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Ubuntu 12.04.1 LTS
java version 1.7.0_07
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
was:
rev 60bf68ca (tagged 1.2.0-beta1-tentative)
[cqlsh 2.2.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | Thrift
protocol 19.34.0]
OS X 10.8.2
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Ubuntu 12.04.1 LTS
java version 1.7.0_07
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
CQL3 CREATE TABLE with set and counter causes
java.lang.IllegalArgumentException
Key: CASSANDRA-4706
URL: https://issues.apache.org/jira/browse/CASSANDRA-4706
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Environment: rev 60bf68ca (tagged 1.2.0-beta1-tentative)
cqlsh 2.2.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | Thrift
protocol 19.34.0
OS X 10.8.2
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Ubuntu 12.04.1 LTS
java version 1.7.0_07
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Reporter: Jonathan Rudenberg
Priority: Blocker
Running a freshly compiled cassandra with non data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4706) CQL3 CREATE TABLE with set and counter causes java.lang.IllegalArgumentException
[
https://issues.apache.org/jira/browse/CASSANDRA-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Rudenberg updated CASSANDRA-4706:
--
Description:
Running a freshly compiled cassandra with no data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
was:
Running a freshly compiled cassandra with non data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
CQL3 CREATE TABLE with set and counter causes
java.lang.IllegalArgumentException
Key: CASSANDRA-4706
URL: https://issues.apache.org/jira/browse/CASSANDRA-4706
Project: Cassandra
Issue Type: Bug
Components:
[jira] [Updated] (CASSANDRA-4706) CQL3 CREATE TABLE with set and counter causes java.lang.IllegalArgumentException
[
https://issues.apache.org/jira/browse/CASSANDRA-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Rudenberg updated CASSANDRA-4706:
--
Description:
Running a freshly compiled cassandra with no data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
was:
Running a freshly compiled cassandra with no data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
CQL3 CREATE TABLE with set and counter causes
java.lang.IllegalArgumentException
Key: CASSANDRA-4706
URL: https://issues.apache.org/jira/browse/CASSANDRA-4706
Project: Cassandra
Issue Type: Bug
Components:
[jira] [Commented] (CASSANDRA-4705) Speculative execution for CL_ONE
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461464#comment-13461464 ] Brandon Williams commented on CASSANDRA-4705: - bq. It would be nice to watch for latency and execute an additional request to a different node Isn't this what the dsnitch does to some degree? Speculative execution for CL_ONE Key: CASSANDRA-4705 URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 Reporter: Vijay Assignee: Vijay Priority: Minor When read_repair is not 1.0, we send the request to one node for some of the requests. When a node goes down or when a node is too busy the client has to wait for the timeout before it can retry. It would be nice to watch for latency and execute an additional request to a different node, if the response is not received within average/99% of the response times recorded in the past. CASSANDRA-2540 might be able to solve the variance when read_repair is set to 1.0 1) May be we need to use metrics-core to record various Percentiles 2) Modify ReadCallback.get to execute additional request speculatively. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4705) Speculative execution for CL_ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461478#comment-13461478
]
Vijay commented on CASSANDRA-4705:
--
No, DSnitch watches for the latency but doesn't do the later It wont
speculate/execute duplicate requests to another host, if the response times are
x%.
I think this patch will be in addition to dsnitch, something like Jonathan
posted in 2540
{quote}
I like the approach described in
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/people/jeff/Berkeley-Latency-Mar2012.pdf
of doing backup requests if the original doesn't reply within N% of normal.
{quote}
Speculative execution for CL_ONE
Key: CASSANDRA-4705
URL: https://issues.apache.org/jira/browse/CASSANDRA-4705
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.0
Reporter: Vijay
Assignee: Vijay
Priority: Minor
When read_repair is not 1.0, we send the request to one node for some of the
requests. When a node goes down or when a node is too busy the client has to
wait for the timeout before it can retry.
It would be nice to watch for latency and execute an additional request to a
different node, if the response is not received within average/99% of the
response times recorded in the past.
CASSANDRA-2540 might be able to solve the variance when read_repair is set to
1.0
1) May be we need to use metrics-core to record various Percentiles
2) Modify ReadCallback.get to execute additional request speculatively.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4707) EOFException during HH delivery
Radim Kolar created CASSANDRA-4707: -- Summary: EOFException during HH delivery Key: CASSANDRA-4707 URL: https://issues.apache.org/jira/browse/CASSANDRA-4707 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Environment: windows Reporter: Radim Kolar i have got following error during HH every replay. I did nodetool scrub on system.hintedhandoff and sstable is not corrupted, it must have invalid data inside. INFO [HintedHandoff:10] 2012-09-23 20:26:21,988 HintedHandOffManager.java (line 294) Started hinted handoff for token: 138224439286689469893643387845607487221 with IP: /10.0.0.9 ERROR [HintedHandoff:10] 2012-09-23 20:26:21,988 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[HintedHandoff:10,1,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:259) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:275) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:232) at edu.stanford.ppl.concurrent.SnapTreeMap.init(SnapTreeMap.java:453) at org.apache.cassandra.db.AtomicSortedColumns$Holder.init(AtomicSortedColumns.java:311) at org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:77) at org.apache.cassandra.db.AtomicSortedColumns.init(AtomicSortedColumns.java:48) at org.apache.cassandra.db.AtomicSortedColumns$1.fromSorted(AtomicSortedColumns.java:61) at org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:399) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:144) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:136) at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:129) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:439) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:447) at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:353) at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:256) at org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:84) at org.apache.cassandra.db.HintedHandOffManager$3.runMayThrow(HintedHandOffManager.java:436) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:197) at java.io.DataInputStream.readFully(DataInputStream.java:169) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:401) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:380) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:88) at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:255) ... 21 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4545) add cql support for batchlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4545: - Comment: was deleted (was: I've done some simple benchmarking using cassandra-stress Inserter and modified Inserter that uses atomic_batch_mutate instead of batch_mutate. I used a three-node cluster, wiped and restarted every machine between test runs. cassandra-stres was being run from a fourth machine. Every batch only contains mutations to one partition key. I'll have to modify Stress more to include mutations of different rows in a batch. The difference will be larger there (regular mutations will be sent to different machines in parallel, but the whole serialized batch itself will still be sent in one piece, and we'll be waiting for at least one response (CL.ONE) before distributing regular mutations). So take the following numbers as the least possible difference between batch_mutate and atomic_batch_mutate or atomic_batch_mutate best case scenario. -n 1000 -c 1 == batch mutate 1000,100,100,0.008556,0 == atomic batch mutate 1000,100,100,0.024504,3 -n 1000 -c 10 == batch mutate 1000,100,100,0.010149,0 == atomic batch mutate 1000,100,100,0.032331,1 -n 1000 -c 100 == batch mutate 1000,100,100,0.038674,2 == atomic batch mutate 1000,100,100,0.041967,2 -n 1000 -c 1000 == batch mutate 1000,100,100,0.088965,4 == atomic batch mutate 1000,100,100,0.136551,6 -n 1000 -c 1 == batch mutate 547,54,54,0.6684040219378428,11 1000,45,45,0.5687505518763797,18 == atomic batch mutate 546,54,54,0.7630347985347985,11 924,37,37,0.768542328042328,21 1000,7,7,1.5153157894736842,24 -n 50 -c 10 == batch mutate 8,0,0,8.057,23 33,2,2,14.80572,33 50,1,1,18.833529411764705,35 == atomic batch mutate 10,1,1,6.5336,20 30,2,2,14.04065,30 40,1,1,27.3045,40 50,1,1,31.8171,46) add cql support for batchlog Key: CASSANDRA-4545 URL: https://issues.apache.org/jira/browse/CASSANDRA-4545 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Need to expose the equivalent of atomic_batch_mutate (CASSANDRA-4542) to CQL3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4545) add cql support for batchlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461582#comment-13461582 ] Aleksey Yeschenko edited comment on CASSANDRA-4545 at 9/24/12 3:01 PM: --- Used a three-node cluster, rah modified cassandra-stress from a separate machine. cassandra-stress was modified to take keys-per-batch parameter. I wiped all the data, ran stress for regular batch mutate (three times for each kpb value, picking the average one), then wiped all the data again and ran the same benchmarks for atomic batch mutate. total in the output is total batches, not total keys (unlike in unmodified cassandra-stress). Default total number of keys was written every time (1M) with 5 columns per key and CL.ONE. # 1 key per batch ## batch_mutate 264131,26413,26413,0.001746815027391711,10 612819,34868,34868,0.0013791584453723674,20 988733,37591,37591,0.001265645865809733,30 100,1126,1126,9.46924647199787E-4,30 ## atomic_batch_mutate 116329,11632,11632,0.0039553851576133205,10 218728,10239,10239,0.0049213175909921,20 341348,12262,12262,0.004092179089871147,30 453569,11222,11222,0.00446199909107921,40 553009,9944,9944,0.005039782783588093,50 657635,10462,10462,0.004790099975149581,60 771908,11427,11427,0.004257716170924015,70 872911,10100,10100,0.005103590982446066,80 970814,9790,9790,0.003992002287978918,90 100,2918,2918,0.00181138216958,93 # 10 keys per batch ## batch_mutate 41456,4145,4145,0.009599430721729063,10 95977,5452,5452,0.00859437647878799,20 10,402,402,0.005297787720606513,21 ## atomic_batch_mutate 31813,3181,3181,0.01379417219375727,10 61825,3001,3001,0.017426962548314006,20 92392,3056,3056,0.013992279255406156,30 10,760,760,0.018285094637223973,34 # 100 keys per batch ## batch_mutate 5414,541,541,0.07286830439601034,10 1,458,458,0.06448626253815962,16 ## atomic_batch_mutate 4560,456,456,0.077079167,10 9037,447,447,0.10926133571588117,20 1,96,96,0.04469574247144341,22 # 1000 keys per batch ## batch_mutate 537,53,53,0.6769962756052141,10 1000,46,46,0.5918012958963282,16 ## atomic_batch_mutate 509,50,50,0.6374538310412574,10 1000,49,49,0.9193156822810591,20 # 1 keys per batch ## batch_mutate 40,4,4,7.91995,19 100,6,6,8.1601832,30 ## atomic_batch_mutate 17,1,1,6.496764705882353,19 36,1,1,11.307736842105264,29 98,6,6,15.237580645161291,40 100,0,0,2.745,40 I don't have an opinion yet regarding making abm the default batch mode, but these are some numbers. Please let me know if you need more (and what kinds of scenarios). was (Author: iamaleksey): Used a three-node cluster, rah modified cassandra-stress from a separate machine. cassandra-stress was modified to take keys-per-batch parameter. I wiped all the data, ran stress for regular batch mutate (three times for each kpb value, picking the average one), then wiped all the data again and ran the same benchmarks for atomic batch mutate. total in the output is total batches, not total keys (unlike in unmodified cassandra-stress). Default total number of keys was written every time (1M) with 5 columns per key and CL.ONE. # 1 key per batch ## batch_mutate 264131,26413,26413,0.001746815027391711,10 612819,34868,34868,0.0013791584453723674,20 988733,37591,37591,0.001265645865809733,30 100,1126,1126,9.46924647199787E-4,30 ## atomic_batch_mutate 116329,11632,11632,0.0039553851576133205,10 218728,10239,10239,0.0049213175909921,20 341348,12262,12262,0.004092179089871147,30 453569,11222,11222,0.00446199909107921,40 553009,9944,9944,0.005039782783588093,50 657635,10462,10462,0.004790099975149581,60 771908,11427,11427,0.004257716170924015,70 872911,10100,10100,0.005103590982446066,80 970814,9790,9790,0.003992002287978918,90 100,2918,2918,0.00181138216958,93 # 10 keys per batch ## batch_mutate 41456,4145,4145,0.009599430721729063,10 95977,5452,5452,0.00859437647878799,20 10,402,402,0.005297787720606513,21 ## atomic_batch_mutate 31813,3181,3181,0.01379417219375727,10 61825,3001,3001,0.017426962548314006,20 92392,3056,3056,0.013992279255406156,30 10,760,760,0.018285094637223973,34 # 100 keys per batch ## batch_mutate 5414,541,541,0.07286830439601034,10 1,458,458,0.06448626253815962,16 ## atomic_batch_mutate 4560,456,456,0.077079167,10 9037,447,447,0.10926133571588117,20 1,96,96,0.04469574247144341,22 # 1000 keys per batch ## batch_mutate 537,53,53,0.6769962756052141,10 1000,46,46,0.5918012958963282,16 ## atomic_batch_mutate 509,50,50,0.6374538310412574,10 1000,49,49,0.9193156822810591,20 # 1 keys per batch ## batch_mutate 40,4,4,7.91995,19 100,6,6,8.1601832,30 ## atomic_batch_mutate 17,1,1,6.496764705882353,19 36,1,1,11.307736842105264,29 98,6,6,15.237580645161291,40 100,0,0,2.745,40 I don't have an opinion yet regarding making abm the default batch mode, but these are some numbers. Please let
[jira] [Commented] (CASSANDRA-4545) add cql support for batchlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461582#comment-13461582 ] Aleksey Yeschenko commented on CASSANDRA-4545: -- Used a three-node cluster, rah modified cassandra-stress from a separate machine. cassandra-stress was modified to take keys-per-batch parameter. I wiped all the data, ran stress for regular batch mutate (three times for each kpb value, picking the average one), then wiped all the data again and ran the same benchmarks for atomic batch mutate. total in the output is total batches, not total keys (unlike in unmodified cassandra-stress). Default total number of keys was written every time (1M) with 5 columns per key and CL.ONE. # 1 key per batch ## batch_mutate 264131,26413,26413,0.001746815027391711,10 612819,34868,34868,0.0013791584453723674,20 988733,37591,37591,0.001265645865809733,30 100,1126,1126,9.46924647199787E-4,30 ## atomic_batch_mutate 116329,11632,11632,0.0039553851576133205,10 218728,10239,10239,0.0049213175909921,20 341348,12262,12262,0.004092179089871147,30 453569,11222,11222,0.00446199909107921,40 553009,9944,9944,0.005039782783588093,50 657635,10462,10462,0.004790099975149581,60 771908,11427,11427,0.004257716170924015,70 872911,10100,10100,0.005103590982446066,80 970814,9790,9790,0.003992002287978918,90 100,2918,2918,0.00181138216958,93 # 10 keys per batch ## batch_mutate 41456,4145,4145,0.009599430721729063,10 95977,5452,5452,0.00859437647878799,20 10,402,402,0.005297787720606513,21 ## atomic_batch_mutate 31813,3181,3181,0.01379417219375727,10 61825,3001,3001,0.017426962548314006,20 92392,3056,3056,0.013992279255406156,30 10,760,760,0.018285094637223973,34 # 100 keys per batch ## batch_mutate 5414,541,541,0.07286830439601034,10 1,458,458,0.06448626253815962,16 ## atomic_batch_mutate 4560,456,456,0.077079167,10 9037,447,447,0.10926133571588117,20 1,96,96,0.04469574247144341,22 # 1000 keys per batch ## batch_mutate 537,53,53,0.6769962756052141,10 1000,46,46,0.5918012958963282,16 ## atomic_batch_mutate 509,50,50,0.6374538310412574,10 1000,49,49,0.9193156822810591,20 # 1 keys per batch ## batch_mutate 40,4,4,7.91995,19 100,6,6,8.1601832,30 ## atomic_batch_mutate 17,1,1,6.496764705882353,19 36,1,1,11.307736842105264,29 98,6,6,15.237580645161291,40 100,0,0,2.745,40 I don't have an opinion yet regarding making abm the default batch mode, but these are some numbers. Please let me know if you need more (and what kind of scenarios). add cql support for batchlog Key: CASSANDRA-4545 URL: https://issues.apache.org/jira/browse/CASSANDRA-4545 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Need to expose the equivalent of atomic_batch_mutate (CASSANDRA-4542) to CQL3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4545) add cql support for batchlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461582#comment-13461582 ] Aleksey Yeschenko edited comment on CASSANDRA-4545 at 9/24/12 3:02 PM: --- Used a three-node cluster, ran modified cassandra-stress from a separate machine. cassandra-stress was modified to take keys-per-batch parameter. I wiped all the data, ran stress for regular batch mutate (three times for each kpb value, picking the average one), then wiped all the data again and ran the same benchmarks for atomic batch mutate. total in the output is total batches, not total keys (unlike in unmodified cassandra-stress). Default total number of keys was written every time (1M) with 5 columns per key and CL.ONE. # 1 key per batch ## batch_mutate 264131,26413,26413,0.001746815027391711,10 612819,34868,34868,0.0013791584453723674,20 988733,37591,37591,0.001265645865809733,30 100,1126,1126,9.46924647199787E-4,30 ## atomic_batch_mutate 116329,11632,11632,0.0039553851576133205,10 218728,10239,10239,0.0049213175909921,20 341348,12262,12262,0.004092179089871147,30 453569,11222,11222,0.00446199909107921,40 553009,9944,9944,0.005039782783588093,50 657635,10462,10462,0.004790099975149581,60 771908,11427,11427,0.004257716170924015,70 872911,10100,10100,0.005103590982446066,80 970814,9790,9790,0.003992002287978918,90 100,2918,2918,0.00181138216958,93 # 10 keys per batch ## batch_mutate 41456,4145,4145,0.009599430721729063,10 95977,5452,5452,0.00859437647878799,20 10,402,402,0.005297787720606513,21 ## atomic_batch_mutate 31813,3181,3181,0.01379417219375727,10 61825,3001,3001,0.017426962548314006,20 92392,3056,3056,0.013992279255406156,30 10,760,760,0.018285094637223973,34 # 100 keys per batch ## batch_mutate 5414,541,541,0.07286830439601034,10 1,458,458,0.06448626253815962,16 ## atomic_batch_mutate 4560,456,456,0.077079167,10 9037,447,447,0.10926133571588117,20 1,96,96,0.04469574247144341,22 # 1000 keys per batch ## batch_mutate 537,53,53,0.6769962756052141,10 1000,46,46,0.5918012958963282,16 ## atomic_batch_mutate 509,50,50,0.6374538310412574,10 1000,49,49,0.9193156822810591,20 # 1 keys per batch ## batch_mutate 40,4,4,7.91995,19 100,6,6,8.1601832,30 ## atomic_batch_mutate 17,1,1,6.496764705882353,19 36,1,1,11.307736842105264,29 98,6,6,15.237580645161291,40 100,0,0,2.745,40 I don't have an opinion yet regarding making abm the default batch mode, but these are some numbers. Please let me know if you need more (and what kinds of scenarios). was (Author: iamaleksey): Used a three-node cluster, rah modified cassandra-stress from a separate machine. cassandra-stress was modified to take keys-per-batch parameter. I wiped all the data, ran stress for regular batch mutate (three times for each kpb value, picking the average one), then wiped all the data again and ran the same benchmarks for atomic batch mutate. total in the output is total batches, not total keys (unlike in unmodified cassandra-stress). Default total number of keys was written every time (1M) with 5 columns per key and CL.ONE. # 1 key per batch ## batch_mutate 264131,26413,26413,0.001746815027391711,10 612819,34868,34868,0.0013791584453723674,20 988733,37591,37591,0.001265645865809733,30 100,1126,1126,9.46924647199787E-4,30 ## atomic_batch_mutate 116329,11632,11632,0.0039553851576133205,10 218728,10239,10239,0.0049213175909921,20 341348,12262,12262,0.004092179089871147,30 453569,11222,11222,0.00446199909107921,40 553009,9944,9944,0.005039782783588093,50 657635,10462,10462,0.004790099975149581,60 771908,11427,11427,0.004257716170924015,70 872911,10100,10100,0.005103590982446066,80 970814,9790,9790,0.003992002287978918,90 100,2918,2918,0.00181138216958,93 # 10 keys per batch ## batch_mutate 41456,4145,4145,0.009599430721729063,10 95977,5452,5452,0.00859437647878799,20 10,402,402,0.005297787720606513,21 ## atomic_batch_mutate 31813,3181,3181,0.01379417219375727,10 61825,3001,3001,0.017426962548314006,20 92392,3056,3056,0.013992279255406156,30 10,760,760,0.018285094637223973,34 # 100 keys per batch ## batch_mutate 5414,541,541,0.07286830439601034,10 1,458,458,0.06448626253815962,16 ## atomic_batch_mutate 4560,456,456,0.077079167,10 9037,447,447,0.10926133571588117,20 1,96,96,0.04469574247144341,22 # 1000 keys per batch ## batch_mutate 537,53,53,0.6769962756052141,10 1000,46,46,0.5918012958963282,16 ## atomic_batch_mutate 509,50,50,0.6374538310412574,10 1000,49,49,0.9193156822810591,20 # 1 keys per batch ## batch_mutate 40,4,4,7.91995,19 100,6,6,8.1601832,30 ## atomic_batch_mutate 17,1,1,6.496764705882353,19 36,1,1,11.307736842105264,29 98,6,6,15.237580645161291,40 100,0,0,2.745,40 I don't have an opinion yet regarding making abm the default batch mode, but these are some numbers. Please let
