Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7E03510772 for ; Fri, 1 Nov 2013 21:00:55 +0000 (UTC) Received: (qmail 79502 invoked by uid 500); 1 Nov 2013 21:00:52 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 79478 invoked by uid 500); 1 Nov 2013 21:00:52 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 79470 invoked by uid 99); 1 Nov 2013 21:00:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Nov 2013 21:00:52 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jdisalive@gmail.com designates 209.85.160.49 as permitted sender) Received: from [209.85.160.49] (HELO mail-pb0-f49.google.com) (209.85.160.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Nov 2013 21:00:46 +0000 Received: by mail-pb0-f49.google.com with SMTP id xb4so4743288pbc.36 for ; Fri, 01 Nov 2013 14:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bQ9usCZ1RAUuVkNDXb+YoD2P29amHbfLKSCh3wi1AEY=; b=AqPP3pQhmsZTQvgspkUc5H9+dTNyyFa6TikXDgauFaR5GG8S1Wdrtvj7+t+EwV8gnq zqdhpQBs0lbjZkLzYRrExumZ+BiZ0MynlBMKR5ibf2A22azjAweww/Vpe66xrRJZ90TG tM2y308Viai+S1AsXBt/vnim5VJC5aMLtU4ACZnZpRmvuPTWmq20Y+lWyVfVZUYa1V9l y7X4jwCUECk+XtvRQ4ceMgTWs8qvbvaTixun45cZa9rHDvcEC/Zu8VpBNu+Epn3bLgGA X5NnnuwSTkrrdND3vJcoq3GIWpf3ARWl3BaeQjAUCcI4Si2KzMgoVem11Bl2zTq11sg1 X1SQ== MIME-Version: 1.0 X-Received: by 10.68.161.2 with SMTP id xo2mr3373603pbb.179.1383339625388; Fri, 01 Nov 2013 14:00:25 -0700 (PDT) Received: by 10.68.32.198 with HTTP; Fri, 1 Nov 2013 14:00:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Nov 2013 17:00:25 -0400 Message-ID: Subject: Re: Cassandra remove column using thrift From: Jayadev Jayaraman To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=047d7bd7562af9a49404ea23dae7 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bd7562af9a49404ea23dae7 Content-Type: text/plain; charset=ISO-8859-1 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 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. > > =Rob > --047d7bd7562af9a49404ea23dae7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey guys,=A0

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


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

My questions wrt this are:
1. Is th= ere a log where I can check whether the remove command registered successfu= lly with the Cassandra nodes?
(In my case, the thrift call was successfully executed but my qu= eries still show data in the deleted column. I don't see logs in the sy= stem.log. )

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

In my understanding, zer= o time. CL.ALL means all replicas have acknowledged the write, and therefor= e the write should be available in the memtables of all nodes.

=3DRob

--047d7bd7562af9a49404ea23dae7--