We drop a column family, recreate it, then read data from a key that existed before dropping, it shouldn’t exist now on cassandra. If we do those operation fast enough, we get old data. If the procedure happen slow enough, we get this exception: org.apache.thrift.TApplicationException: Internal error processing get_slice
On client: "org.apache.thrift.TApplicationException: Internal error processing
On server: [org.apache.cassandra.thrift.Cassandra$Processor] (pool-1-thread-4 -
Internal error processing get_slice
yes. See above section.
0.7 beta 2
1) drop column family (file write)
2) recreate the dropped column family (file write)
3) read data from a key that existed before dropping, but doesn’t exist now (file read)
yes (operations must be performed very fast or very slow)
yes. See exception section.
We performing these three actions in succession: drop column family, recreate it, read data from a key that existed before dropping, but doesn’t exist now. If done too fast, we receive stale data. If done too slow we get "org.apache.thrift.TApplicationException: Internal error processing get_slice" on client side and java.lang.RuntimeException: java.util.concurrent.ExecutionException:, java.io.IOError: java.io.FileNotFoundException: on the server side.
With some domain knowledge, the developer knows the way to cleanup after dropped column family has changed. Previous to the change, there is a block on delete. Now instead of blocking on delete, we mark the column family as compacted and waiting for normal cleanup to do the job. With this change, we introduce a race condition.
race condition between deletion and creation of column family.
When creating a column family, ensure that its data directory, if it exists, is empty. This avoids the race condition.