Hey guys, 

False alarm, sorry about that. Our column-names are byte-concatenations of short integers and we had been constructing the column names wrongly before attempting a delete. We fixed the problem and we've been able to delete the columns without issue. 

On Fri, Nov 1, 2013 at 4:19 PM, Robert Coli <rcoli@eventbrite.com> wrote:
On Fri, Nov 1, 2013 at 8:15 AM, Suruchi Deodhar <suruchi.deodhar@generalsentiment.com> wrote:
I provide the timestamp as the current time and consistency_level=ConsistencyLevel.ALL.

My questions wrt this are:
1. Is there a log where I can check whether the remove command registered successfully with the Cassandra nodes?
(In my case, the thrift call was successfully executed but my queries still show data in the deleted column. I don't see logs in the system.log. )

This sounds unexpected. Have you tried deleting the same column via cassandra-cli or cqlsh (as applicable)? If so, does it work?
2. Given that consistency_level=ConsistencyLevel.ALL, how much time does cassandra take to commit the delete and cassandra client to get updated data?

In my understanding, zero time. CL.ALL means all replicas have acknowledged the write, and therefore the write should be available in the memtables of all nodes.