[jira] [Commented] (CASSANDRA-6140) Cassandra-cli backward compatibility issue with Cassandra 2.0.1
[
https://issues.apache.org/jira/browse/CASSANDRA-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812275#comment-13812275
]
Dave Brosius commented on CASSANDRA-6140:
-
As an aside, is there a reason to allow a single component composite, as above:
CompositeType(UTF8Type)
Cassandra-cli backward compatibility issue with Cassandra 2.0.1
---
Key: CASSANDRA-6140
URL: https://issues.apache.org/jira/browse/CASSANDRA-6140
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Linux Ubuntu, Cassandra 2.0.0
Reporter: DOAN DuyHai
Currently we are using Cassandra 1.2.6 and we want to migrate to 2.0.1.
We still use Thrift for some column families (migration to CQL3 is not done
yet for them). We have cassandra-cli script to drop/create fresh keyspace,
re-create column families and populate referential data:
*Schema creation script*
{code}
drop keyspace xxx;
create keyspace xxx with placement_strategy ...
create column family offers with
key_validation_class = UTF8Type and
comparator = 'CompositeType(UTF8Type)' and
default_validation_class = UTF8Type;
{code}
*Data insertion script*:
{code}
set offers['OFFER1'][PRODUCT1']='test_product';
...
{code}
When executing the data insertion script with Cassandra 2.0.1, we have the
following stack trace:
{code}
Invalid cell for CQL3 table offers. The CQL3 column component (COL1) does not
correspond to a defined CQL3 column
InvalidRequestException(why:Invalid cell for CQL3 table offers. The CQL3
column component (COL1) does not correspond to a defined CQL3 column)
at
org.apache.cassandra.thrift.Cassandra$insert_result$insert_resultStandardScheme.read(Cassandra.java:21447)
at
org.apache.cassandra.thrift.Cassandra$insert_result$insert_resultStandardScheme.read(Cassandra.java:21433)
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:21367)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:898)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:882)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:987)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:231)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:201)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:327)
{code}
This data insertion script works pecfectly with Cassandra 1.2.6.
We face the same issue with Cassandra 2.0.0. It looks like the cassandra-cli
commands no longer works with Cassandra 2.0.0...
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6140) Cassandra-cli backward compatibility issue with Cassandra 2.0.1
[
https://issues.apache.org/jira/browse/CASSANDRA-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812302#comment-13812302
]
DOAN DuyHai commented on CASSANDRA-6140:
As an aside, is there a reason to allow a single component composite
Yes, we want to be able to query with strict inequality on 'PRODUCT', they are
ordered by name
Cassandra-cli backward compatibility issue with Cassandra 2.0.1
---
Key: CASSANDRA-6140
URL: https://issues.apache.org/jira/browse/CASSANDRA-6140
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Linux Ubuntu, Cassandra 2.0.0
Reporter: DOAN DuyHai
Currently we are using Cassandra 1.2.6 and we want to migrate to 2.0.1.
We still use Thrift for some column families (migration to CQL3 is not done
yet for them). We have cassandra-cli script to drop/create fresh keyspace,
re-create column families and populate referential data:
*Schema creation script*
{code}
drop keyspace xxx;
create keyspace xxx with placement_strategy ...
create column family offers with
key_validation_class = UTF8Type and
comparator = 'CompositeType(UTF8Type)' and
default_validation_class = UTF8Type;
{code}
*Data insertion script*:
{code}
set offers['OFFER1'][PRODUCT1']='test_product';
...
{code}
When executing the data insertion script with Cassandra 2.0.1, we have the
following stack trace:
{code}
Invalid cell for CQL3 table offers. The CQL3 column component (COL1) does not
correspond to a defined CQL3 column
InvalidRequestException(why:Invalid cell for CQL3 table offers. The CQL3
column component (COL1) does not correspond to a defined CQL3 column)
at
org.apache.cassandra.thrift.Cassandra$insert_result$insert_resultStandardScheme.read(Cassandra.java:21447)
at
org.apache.cassandra.thrift.Cassandra$insert_result$insert_resultStandardScheme.read(Cassandra.java:21433)
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:21367)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:898)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:882)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:987)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:231)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:201)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:327)
{code}
This data insertion script works pecfectly with Cassandra 1.2.6.
We face the same issue with Cassandra 2.0.0. It looks like the cassandra-cli
commands no longer works with Cassandra 2.0.0...
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CASSANDRA-6292) CQL should be able to do a delete with a or operator on a clustering portion of a primary key
[ https://issues.apache.org/jira/browse/CASSANDRA-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-6292. - Resolution: Duplicate CQL should be able to do a delete with a or operator on a clustering portion of a primary key -- Key: CASSANDRA-6292 URL: https://issues.apache.org/jira/browse/CASSANDRA-6292 Project: Cassandra Issue Type: Improvement Components: API Reporter: Tupshin Harper Assignee: Jonathan Ellis Fix For: 2.1 The following creates a table that at the storage engine level, has key as the row key, and evt as a time ordered list of columns within the row: create table test (key text, evt timestamp, primary key(key,evt)) with clustering order by (evt asc); Given the ability to create slice tombstones (both implicitly by deleting collections and supercolumns) as well as in thrift through a delete with a slice predicate. Given the schema above, the expected syntax to delete all columns with key one and timestamp less than 1000 would be: delete from test where key='one' and evt 1000; and if you did that as well as delete from test where key='one' and evt 1000; You would accomplish exactly what is being asked about (in terms of thrift and astyanax) here: http://stackoverflow.com/questions/19747005/delete-all-the-columns-and-its-data-except-for-one-columns-using-astyanax-client -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6107) CQL3 Batch statement memory leak
[ https://issues.apache.org/jira/browse/CASSANDRA-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812415#comment-13812415 ] Michael Oczkowski commented on CASSANDRA-6107: -- This change appears to break code that uses EmbeddedCassandraService and PreparedStatements in version 1.2.11. Please see CASSANDRA-6293 for details. CQL3 Batch statement memory leak Key: CASSANDRA-6107 URL: https://issues.apache.org/jira/browse/CASSANDRA-6107 Project: Cassandra Issue Type: Bug Components: API, Core Environment: - CASS version: 1.2.8 or 2.0.1, same issue seen in both - Running on OSX MacbookPro - Sun JVM 1.7 - Single local cassandra node - both CMS and G1 GC used - we are using the cass-JDBC driver to submit our batches Reporter: Constance Eustace Assignee: Lyuben Todorov Priority: Minor Fix For: 1.2.11 Attachments: 6107-v4.txt, 6107.patch, 6107_v2.patch, 6107_v3.patch, Screen Shot 2013-10-03 at 17.59.37.png We are doing large volume insert/update tests on a CASS via CQL3. Using 4GB heap, after roughly 750,000 updates create/update 75,000 row keys, we run out of heap, and it never dissipates, and we begin getting this infamous error which many people seem to be encountering: WARN [ScheduledTasks:1] 2013-09-26 16:17:10,752 GCInspector.java (line 142) Heap is 0.9383457210434385 full. You may need to reduce memtable and/or cache sizes. Cassandra will now flush up to the two largest memtables to free up memory. Adjust flush_largest_memtables_at threshold in cassandra.yaml if you don't want Cassandra to do this automatically INFO [ScheduledTasks:1] 2013-09-26 16:17:10,753 StorageService.java (line 3614) Unable to reduce heap usage since there are no dirty column families 8 and 12 GB heaps appear to delay the problem by roughly proportionate amounts of 75,000 - 100,000 rowkeys per 4GB. Each run of 50,000 row key creations sees the heap grow and never shrink again. We have attempted to no effect: - removing all secondary indexes to see if that alleviates overuse of bloom filters - adjusted parameters for compaction throughput - adjusted memtable flush thresholds and other parameters By examining heapdumps, it seems apparent that the problem is perpetual retention of CQL3 BATCH statements. We have even tried dropping the keyspaces after the updates and the CQL3 statement are still visible in the heapdump, and after many many many CMS GC runs. G1 also showed this issue. The 750,000 statements are broken into batches of roughly 200 statements. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CASSANDRA-6293) CASSANDRA-6107 causes EmbeddedCassandraService to fail
Michael Oczkowski created CASSANDRA-6293: Summary: CASSANDRA-6107 causes EmbeddedCassandraService to fail Key: CASSANDRA-6293 URL: https://issues.apache.org/jira/browse/CASSANDRA-6293 Project: Cassandra Issue Type: Bug Components: Core Reporter: Michael Oczkowski Starting with 1.2.11 calling statement.prepare() when running EmbeddedCassandraService causes an exception due to missing Java agent. Prior to 1.2.11 this never caused an exception, though there were warnings in the logs about the missing agent. 2013-11-01 11:14:06,508 ERROR Native-Transport-Requests:109 org.apache.cassandra.transport.messages.ErrorMessage - Unexpected exception during request java.lang.IllegalStateException: Instrumentation is not set; Jamm must be set as -javaagent at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:70) at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:102) at org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:214) at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:202) at org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77) at org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43) at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67) 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:722) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-5981) Netty frame length exception when storing data to Cassandra using binary protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812466#comment-13812466
]
Daniel Norberg commented on CASSANDRA-5981:
---
Looks good, thumbs up.
Netty frame length exception when storing data to Cassandra using binary
protocol
-
Key: CASSANDRA-5981
URL: https://issues.apache.org/jira/browse/CASSANDRA-5981
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux, Java 7
Reporter: Justin Sweeney
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0.3
Attachments: 0001-Correctly-catch-frame-too-long-exceptions.txt,
0002-Allow-to-configure-the-max-frame-length.txt, 5981-v2.txt, 5981-v3.txt
Using Cassandra 1.2.8, I am running into an issue where when I send a large
amount of data using the binary protocol, I get the following netty exception
in the Cassandra log file:
{quote}
ERROR 09:08:35,845 Unexpected exception during request
org.jboss.netty.handler.codec.frame.TooLongFrameException: Adjusted frame
length exceeds 268435456: 292413714 - discarded
at
org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.fail(LengthFieldBasedFrameDecoder.java:441)
at
org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.failIfNecessary(LengthFieldBasedFrameDecoder.java:412)
at
org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.decode(LengthFieldBasedFrameDecoder.java:372)
at org.apache.cassandra.transport.Frame$Decoder.decode(Frame.java:181)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:422)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at
org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:84)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:472)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:333)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
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)
{quote}
I am using the Datastax driver and using CQL to execute insert queries. The
query that is failing is using atomic batching executing a large number of
statements (~55).
Looking into the code a bit, I saw that in the
org.apache.cassandra.transport.Frame$Decoder class, the MAX_FRAME_LENGTH is
hard coded to 256 mb.
Is this something that should be configurable or is this a hard limit that
will prevent batch statements of this size from executing for some reason?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6293) CASSANDRA-6107 causes EmbeddedCassandraService to fail
[ https://issues.apache.org/jira/browse/CASSANDRA-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6293: -- Priority: Minor (was: Major) Issue Type: Wish (was: Bug) Running with JAMM isn't really supported but you're welcome to contribute an alternative. CASSANDRA-6107 causes EmbeddedCassandraService to fail -- Key: CASSANDRA-6293 URL: https://issues.apache.org/jira/browse/CASSANDRA-6293 Project: Cassandra Issue Type: Wish Components: Core Reporter: Michael Oczkowski Priority: Minor Starting with 1.2.11 calling statement.prepare() when running EmbeddedCassandraService causes an exception due to missing Java agent. Prior to 1.2.11 this never caused an exception, though there were warnings in the logs about the missing agent. 2013-11-01 11:14:06,508 ERROR Native-Transport-Requests:109 org.apache.cassandra.transport.messages.ErrorMessage - Unexpected exception during request java.lang.IllegalStateException: Instrumentation is not set; Jamm must be set as -javaagent at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:70) at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:102) at org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:214) at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:202) at org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77) at org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43) at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67) 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:722) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CASSANDRA-6293) CASSANDRA-6107 causes EmbeddedCassandraService to fail
[ https://issues.apache.org/jira/browse/CASSANDRA-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812487#comment-13812487 ] Jonathan Ellis edited comment on CASSANDRA-6293 at 11/3/13 9:04 PM: Running without JAMM isn't really supported but you're welcome to contribute an alternative. was (Author: jbellis): Running with JAMM isn't really supported but you're welcome to contribute an alternative. CASSANDRA-6107 causes EmbeddedCassandraService to fail -- Key: CASSANDRA-6293 URL: https://issues.apache.org/jira/browse/CASSANDRA-6293 Project: Cassandra Issue Type: Wish Components: Core Reporter: Michael Oczkowski Priority: Minor Starting with 1.2.11 calling statement.prepare() when running EmbeddedCassandraService causes an exception due to missing Java agent. Prior to 1.2.11 this never caused an exception, though there were warnings in the logs about the missing agent. 2013-11-01 11:14:06,508 ERROR Native-Transport-Requests:109 org.apache.cassandra.transport.messages.ErrorMessage - Unexpected exception during request java.lang.IllegalStateException: Instrumentation is not set; Jamm must be set as -javaagent at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:70) at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:102) at org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:214) at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:202) at org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77) at org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43) at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67) 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:722) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CASSANDRA-6294) AssertionError computing Merkle tree for repair
Jiri Horky created CASSANDRA-6294: - Summary: AssertionError computing Merkle tree for repair Key: CASSANDRA-6294 URL: https://issues.apache.org/jira/browse/CASSANDRA-6294 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jiri Horky Fix For: 2.0.3 Trying to run nodetool repair on our 2.0.0 cluster results in : INFO [CompactionExecutor:1652] 2013-11-03 22:11:15,749 CompactionController.java (line 194) Compacting large row fr/sha:cbe2392792d209e15e44ac29e906ffdd5fbf6eed8bab0d97d66e109ab2c5c56e (103158300 bytes) incrementally ERROR [ValidationExecutor:8] 2013-11-03 22:11:51,918 Validator.java (line 197) Failed creating a merkle tree for [repair #5fed6f20-44cc-11e3-b77c-6b91d59c0c0e on fr/sha, (2,21267647932558653966460912964485513216]], /10.10.10.12 (see log for details) ERROR [ValidationExecutor:8] 2013-11-03 22:11:51,919 CassandraDaemon.java (line 186) Exception in thread Thread[ValidationExecutor:8,1,main] java.lang.AssertionError at org.apache.cassandra.db.compaction.PrecompactedRow.update(PrecompactedRow.java:165) at org.apache.cassandra.repair.Validator.rowHash(Validator.java:161) at org.apache.cassandra.repair.Validator.add(Validator.java:153) at org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:669) at org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:64) at org.apache.cassandra.db.compaction.CompactionManager$8.call(CompactionManager.java:395) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) 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:722) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CASSANDRA-6294) AssertionError computing Merkle tree for repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-6294. --- Resolution: Duplicate Fixed in CASSANDRA-6277 AssertionError computing Merkle tree for repair --- Key: CASSANDRA-6294 URL: https://issues.apache.org/jira/browse/CASSANDRA-6294 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jiri Horky Fix For: 2.0.3 Trying to run nodetool repair on our 2.0.0 cluster results in : INFO [CompactionExecutor:1652] 2013-11-03 22:11:15,749 CompactionController.java (line 194) Compacting large row fr/sha:cbe2392792d209e15e44ac29e906ffdd5fbf6eed8bab0d97d66e109ab2c5c56e (103158300 bytes) incrementally ERROR [ValidationExecutor:8] 2013-11-03 22:11:51,918 Validator.java (line 197) Failed creating a merkle tree for [repair #5fed6f20-44cc-11e3-b77c-6b91d59c0c0e on fr/sha, (2,21267647932558653966460912964485513216]], /10.10.10.12 (see log for details) ERROR [ValidationExecutor:8] 2013-11-03 22:11:51,919 CassandraDaemon.java (line 186) Exception in thread Thread[ValidationExecutor:8,1,main] java.lang.AssertionError at org.apache.cassandra.db.compaction.PrecompactedRow.update(PrecompactedRow.java:165) at org.apache.cassandra.repair.Validator.rowHash(Validator.java:161) at org.apache.cassandra.repair.Validator.add(Validator.java:153) at org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:669) at org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:64) at org.apache.cassandra.db.compaction.CompactionManager$8.call(CompactionManager.java:395) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) 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:722) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6146) CQL-native stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812543#comment-13812543 ] Mikhail Stepura commented on CASSANDRA-6146: Is it worth trying to implement CQL (via DataStax Java Driver) plugin for JMeter? It would allow users to build their own test plans? https://jmeter.apache.org/usermanual/build-db-test-plan.html https://github.com/Netflix/CassJMeter CQL-native stress - Key: CASSANDRA-6146 URL: https://issues.apache.org/jira/browse/CASSANDRA-6146 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis The existing CQL support in stress is not worth discussing. We need to start over, and we might as well kill two birds with one stone and move to the native protocol while we're at it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6293) CASSANDRA-6107 causes EmbeddedCassandraService to fail
[
https://issues.apache.org/jira/browse/CASSANDRA-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-6293:
---
Attachment: CASSANDRA-1.2-6293.patch
We can fallback to the old approach (with {{MAX_CACHE_PREPARED = 10}} if
JAMM is not configured.
CASSANDRA-6107 causes EmbeddedCassandraService to fail
--
Key: CASSANDRA-6293
URL: https://issues.apache.org/jira/browse/CASSANDRA-6293
Project: Cassandra
Issue Type: Wish
Components: Core
Reporter: Michael Oczkowski
Priority: Minor
Attachments: CASSANDRA-1.2-6293.patch
Starting with 1.2.11 calling statement.prepare() when running
EmbeddedCassandraService causes an exception due to missing Java agent.
Prior to 1.2.11 this never caused an exception, though there were warnings in
the logs about the missing agent.
2013-11-01 11:14:06,508 ERROR Native-Transport-Requests:109
org.apache.cassandra.transport.messages.ErrorMessage - Unexpected exception
during request
java.lang.IllegalStateException: Instrumentation is not set; Jamm must be set
as -javaagent
at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:70)
at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:102)
at
org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:214)
at
org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:202)
at
org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
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:722)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6146) CQL-native stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812568#comment-13812568 ] Jonathan Ellis commented on CASSANDRA-6146: --- Dunno, I don't have any experience with that. Maybe [~enigmacurry] or [~jasobrown]? CQL-native stress - Key: CASSANDRA-6146 URL: https://issues.apache.org/jira/browse/CASSANDRA-6146 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis The existing CQL support in stress is not worth discussing. We need to start over, and we might as well kill two birds with one stone and move to the native protocol while we're at it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6146) CQL-native stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812575#comment-13812575 ] Ryan McGuire commented on CASSANDRA-6146: - No experience here with JMeter, but it certainly looks cool. I do like the idea of introspecting tables and accommodating for that, but I don't want that at the cost of the ease of use either - one thing that's nice with stress currently is that it works without any setup/parameters on a local database. CQL-native stress - Key: CASSANDRA-6146 URL: https://issues.apache.org/jira/browse/CASSANDRA-6146 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis The existing CQL support in stress is not worth discussing. We need to start over, and we might as well kill two birds with one stone and move to the native protocol while we're at it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CASSANDRA-6146) CQL-native stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812543#comment-13812543 ] Mikhail Stepura edited comment on CASSANDRA-6146 at 11/4/13 2:20 AM: - Is it worth trying to implement CQL (via DataStax Java Driver) plugin for JMeter? It would allow users to build their own test plans. https://jmeter.apache.org/usermanual/build-db-test-plan.html https://github.com/Netflix/CassJMeter was (Author: mishail): Is it worth trying to implement CQL (via DataStax Java Driver) plugin for JMeter? It would allow users to build their own test plans? https://jmeter.apache.org/usermanual/build-db-test-plan.html https://github.com/Netflix/CassJMeter CQL-native stress - Key: CASSANDRA-6146 URL: https://issues.apache.org/jira/browse/CASSANDRA-6146 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis The existing CQL support in stress is not worth discussing. We need to start over, and we might as well kill two birds with one stone and move to the native protocol while we're at it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6146) CQL-native stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812579#comment-13812579 ] Mikhail Stepura commented on CASSANDRA-6146: bq. but I don't want that at the cost of the ease of use either - one thing that's nice with stress currently is that it works without any setup/parameters on a local database. We can create a few JMeter plans which will cover existing stress tool functionality and will work with local instance by default. Users would use them as a basis CQL-native stress - Key: CASSANDRA-6146 URL: https://issues.apache.org/jira/browse/CASSANDRA-6146 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis The existing CQL support in stress is not worth discussing. We need to start over, and we might as well kill two birds with one stone and move to the native protocol while we're at it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6146) CQL-native stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812582#comment-13812582 ] Ryan McGuire commented on CASSANDRA-6146: - Sounds good to me in that case. CQL-native stress - Key: CASSANDRA-6146 URL: https://issues.apache.org/jira/browse/CASSANDRA-6146 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis The existing CQL support in stress is not worth discussing. We need to start over, and we might as well kill two birds with one stone and move to the native protocol while we're at it. -- This message was sent by Atlassian JIRA (v6.1#6144)
