cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramzi Rabah (JIRA)" <j...@apache.org>
Subject [jira] Created: (CASSANDRA-507) Tombstone records in Cassandra are not being deleted
Date Wed, 21 Oct 2009 19:30:59 GMT
Tombstone records in Cassandra are not being deleted
----------------------------------------------------

                 Key: CASSANDRA-507
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-507
             Project: Cassandra
          Issue Type: Bug
          Components: Core
    Affects Versions: 0.4
            Reporter: Ramzi Rabah


I am running into problems with get_key_range.
My command is client.get_key_range("Keyspace1", "DatastoreDeletionSchedule",
                   "", "", 25, ConsistencyLevel.ONE);

After a lot of deletes on the datastore, I am getting 

ERROR [pool-1-thread-36] 2009-10-19 17:24:28,223 Cassandra.java (line
770) Internal error processing get_key_range
java.lang.RuntimeException: java.util.concurrent.TimeoutException:
Operation timed out.
       at org.apache.cassandra.service.StorageProxy.getKeyRange(StorageProxy.java:560)
       at org.apache.cassandra.service.CassandraServer.get_key_range(CassandraServer.java:595)
       at org.apache.cassandra.service.Cassandra$Processor$get_key_range.process(Cassandra.java:766)
       at org.apache.cassandra.service.Cassandra$Processor.process(Cassandra.java:609)
       at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:253)
       at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
       at java.lang.Thread.run(Thread.java:619)
Caused by: java.util.concurrent.TimeoutException: Operation timed out.
       at org.apache.cassandra.net.AsyncResult.get(AsyncResult.java:97)
       at org.apache.cassandra.service.StorageProxy.getKeyRange(StorageProxy.java:556)
       ... 7 more

Turns out that the compaction code removes tombstones, and it runs whenever you have
enough sstable fragments. As an optimization, if there is
only one version of a row it will just copy it to the new sstable.
This means it won't clean out tombstones, which is causing this problem.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message