From user-return-18367-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Sat Jul 2 12:04:25 2011 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 872CC6F64 for ; Sat, 2 Jul 2011 12:04:25 +0000 (UTC) Received: (qmail 99154 invoked by uid 500); 2 Jul 2011 12:04:23 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 98848 invoked by uid 500); 2 Jul 2011 12:04:21 -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 98840 invoked by uid 99); 2 Jul 2011 12:04:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jul 2011 12:04:21 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 209.85.214.44 is neither permitted nor denied by domain of oberman@civicscience.com) Received: from [209.85.214.44] (HELO mail-bw0-f44.google.com) (209.85.214.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jul 2011 12:04:15 +0000 Received: by bwb17 with SMTP id 17so3789482bwb.31 for ; Sat, 02 Jul 2011 05:03:55 -0700 (PDT) Received: by 10.204.41.16 with SMTP id m16mr4090432bke.151.1309608235005; Sat, 02 Jul 2011 05:03:55 -0700 (PDT) References: <4E0E7A07.2050807@dude.podzone.net> <2B2CF529-F505-40C0-9663-36907FB3FA34@civicscience.com> <7d70b195-e8cb-4ad9-93d2-af5ce928fa6b@email.android.com> From: William Oberman In-Reply-To: <7d70b195-e8cb-4ad9-93d2-af5ce928fa6b@email.android.com> Mime-Version: 1.0 (iPad Mail 8J3) Date: Sat, 2 Jul 2011 08:03:55 -0400 Message-ID: <8910389677256918425@unknownmsgid> Subject: Re: Strong Consistency with ONE read/writes To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=bcaec5555206a4784404a714edff X-Virus-Checked: Checked by ClamAV on apache.org --bcaec5555206a4784404a714edff Content-Type: text/plain; charset=ISO-8859-1 Ok, I see the "you happen to choose the 'right' node" idea, but it sounds like you want to solve "C* problems" in the client, and they already wrote that complicated code to make clients simple. You're talking about reimplementing key<->node mappings, network topology (with failures), etc... Plus, if they change something about replication and you get too tricky, your code breaks. Or, if they optimize something, you might not benefit. On Jul 1, 2011, at 10:33 PM, AJ wrote: I'm saying I will make my clients forward the C* requests to the first replica instead of forwarding to a random node. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Will Oberman wrote: > > > > Sent from my iPhone > > On Jul 1, 2011, at 9:53 PM, AJ wrote: > > > Is this possible? > > > > All reads and writes for a given key will always go to the same node > > from a client. > > I don't think that's true. Given a key K, the client will write to N > nodes (N=replication factor). And at consistency level ONE the client > will return after 1 "ack" (from the N writes). > > --bcaec5555206a4784404a714edff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, I see the "you happen to choo= se the 'right' node" idea, but=A0it sounds like you want to = solve "C* problems" in the client, and they already wrote that co= mplicated code to make clients simple. =A0 You're talking about reimple= menting key<->node mappings, network topology (with failures), etc...= =A0Plus, if they change something about replication and you get too tricky= , your code breaks. =A0Or, if they optimize something, you might not benefi= t.=A0

On Jul 1, 2011, at 10:33 PM, AJ <aj@dude.podzone.net> wrote:

I'm saying I will make my clients forward the C= * requests to the first replica instead of forwarding to a random node.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

=
Will Oberman <oberman@civicscience.com> wrote:


Sent from my iPhone

On Jul 1, 2011, at 9:53 PM, AJ = <aj@dude.podzone.net> wrot= e:

> Is this possible?
>
> All reads and writes for a given= key will always go to the same node
> from a client.

I don&= #39;t think that's true. Given a key K, the client will write to N nodes (N=3Dreplication factor). And at consistency level ONE the client will return after 1 "ack" (from the N writes).

=
--bcaec5555206a4784404a714edff--