datastax

Blocking execute fethod from com.datastax.driver.core.Session public ResultSet execute(Statement statement); Comment on this method: This method blocks until at least some result has been received from the database. However, for SELECT queries, it does not guarantee that the result has been received in full. But it does guarantee that some response has been received from the database, and in particular guarantee that if the request is invalid, an exception will be thrown by this method. Non-blocking execute fethod from com.datastax.driver.core.Session public ResultSetFuture executeAsync

I have been using Pig with my Cassandra data to do all kinds of amazing feats of groupings that would be almost impossible to write imperatively. I am using DataStax's integration of Hadoop & Cassandra, and I have to say it is quite impressive. Hat-off to those guys!! I have a pretty small sandbox cluster (2-nodes) where I am putting this system thru some tests. I have a CQL table that has ~53M rows (about 350 bytes ea.), and I notice that the Mapper later takes a very long time to grind thru these 53M rows. I started poking around the logs and I can see that the map is spilling repeatedly (i

I'm running a two node Datastax AMI cluster on AWS. Yesterday, Cassandra started refusing connections from everything. The system logs showed nothing. After a lot of tinkering, I discovered that the commit logs had filled up all the disk space on the allotted mount and this seemed to be causing the connection refusal (deleted some of the commit logs, restarted and was able to connect). I'm on DataStax AMI 2.5.1 and Cassandra 2.1.7 If I decide to wipe and restart everything from scratch, how do I ensure that this does not happen again? You could try lowering the commitlog_total_space_in_mb

The exact Exception is as follows com.datastax.driver.core.exceptions.CodecNotFoundException: Codec not found for requested operation: [varchar <-> java.math.BigDecimal] These are the versions of Software I am using Spark 1.5 Datastax-cassandra 3.2.1 CDH 5.5.1 The code I am trying to execute is a Spark program using the java api and it basically reads data (csv's) from hdfs and loads it into cassandra tables . I am using the spark-cassandra-connector. I had a lot of issues regarding the google s guava library conflict initially which I was able to resolve by shading the guava library and

I have recently lowered gc_grace_seconds for a CQL table. I am running LeveledCompactionStrategy . Is it possible for me to force purging of old tombstones from my SSTables? TL;DR Your tombstones will disappear on their own through compaction bit make sure you are running repair or they may come back from the dead. http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_about_deletes_c.html Adding some more details: Tombstones are not immediately available for deletion until both: 1) gc_grace_seconds has expired 2) they meet the requirements configured in tombstone compaction sub

Our current setup contain DSE 5.0.2 version with 3 node cluster.Currently we are facing issue with heavy load and node failure issue.Debug.log details is given below: DEBUG [ReadRepairStage:8] 2016-09-27 14:11:58,781 ReadCallback.java:234 - Digest mismatch: org.apache.cassandra.service.DigestMismatchException: Mismatch for key DecoratedKey(5503649670304043860, 343233) (45cf191fb10d902dc052aa76f7f0b54d vs ffa7b4097e7fa05de794371092c51c68) at org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:85) ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159] at org.apache.cassandra.service