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 03130C710 for ; Mon, 10 Mar 2014 14:32:15 +0000 (UTC) Received: (qmail 2460 invoked by uid 500); 10 Mar 2014 14:32:11 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 2426 invoked by uid 500); 10 Mar 2014 14:32:10 -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 2407 invoked by uid 99); 10 Mar 2014 14:32:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Mar 2014 14:32:08 +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 (athena.apache.org: domain of eric.plowe@gmail.com designates 209.85.219.52 as permitted sender) Received: from [209.85.219.52] (HELO mail-oa0-f52.google.com) (209.85.219.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Mar 2014 14:32:03 +0000 Received: by mail-oa0-f52.google.com with SMTP id l6so7022033oag.39 for ; Mon, 10 Mar 2014 07:31:43 -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=aDfM2TPJaMgvN52ju+ZpOgkSSK4DTXPWOnKEoYft5Fk=; b=Wv8pqJnkAZM7aEifzuH4X4j/sDosYzgKy+lMaytGxAc2Gr60jQl8F9iI/bhIqU7VzN JrazU73cfozbicVhaRX4HpoG7eyt/J7/ajjN+EMECHeobahZnfzu+w9r8ekAblWu1Buq rPhx/MwXwX9E9J8slvGILGK5VUSYLY5DDeDHMcr0lbzfRzVVTOqXrToBgFmJE7HSMlXc yqqjp5lP8Bdm9f6ycL7jf6Uh17V0XIQlVvtDiqBd9oB5/gemW9W5GhQQnKBr322X/yxh GyWmrHyD/iABqls2hXZ9JXm5pTleOH3Zy+Ri/inPbBgNe+v2z7e49Tt07AtV3by/zAln A3Ww== MIME-Version: 1.0 X-Received: by 10.60.44.42 with SMTP id b10mr760546oem.70.1394461902864; Mon, 10 Mar 2014 07:31:42 -0700 (PDT) Received: by 10.182.191.104 with HTTP; Mon, 10 Mar 2014 07:31:42 -0700 (PDT) In-Reply-To: <26833_1394460369_531DC6D1_26833_3334_4_9C88BF562A27AA41B242B2780441926E21186EC56A@THSONEA01CMS05P.one.grp> References: <30839_1394455792_531DB4F0_30839_1631_1_40fabc34-0c26-462c-9424-058ca1536cc0@THSONEA01HUB03P.one.grp> <531DC470.9070903@pbandjelly.org> <26833_1394460369_531DC6D1_26833_3334_4_9C88BF562A27AA41B242B2780441926E21186EC56A@THSONEA01CMS05P.one.grp> Date: Mon, 10 Mar 2014 10:31:42 -0400 Message-ID: Subject: Re: sending notifications through data replication on remote clusters From: Eric Plowe To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11c30a045f870904f44176cb X-Virus-Checked: Checked by ClamAV on apache.org --001a11c30a045f870904f44176cb Content-Type: text/plain; charset=ISO-8859-1 You should be able to achieve what you're looking for with a trigger vs. a modification to the core of Cassandra. http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-0-prototype-triggers-support On Mon, Mar 10, 2014 at 10:06 AM, DE VITO Dominique < dominique.devito@thalesgroup.com> wrote: > > On 03/10/2014 07:49 AM, DE VITO Dominique wrote: > > > If I update a data on DC1, I just want apps "connected-first" to DC2 > > > to be informed when this data is available on DC2 after replication. > > > > If I run a SELECT, I'm going to receive the latest data per the read > conditions (ONE, TWO, QUORUM), regardless of location of the client > connection. If using > network aware topology, you'll get the most current > data in that DC. > > > > > When using Thrift, one way could be to modify CassandraServer class, > > > to send notification to apps according to data coming in into the > > > coordinator node of DC2. > > > > > > Is it "common" (~ the way to do it) ? > > > > > > Is there another way to do so ? > > > > > > When using CQL, is there a precise "src code" place to modify for the > > > same purpose ? > > > > Notifying connected clients about random INSERT or UPDATE statements > that ran somewhere seems to be far, far outside the scope of storing data. > Just configure your client to SELECT in the manner that you need. > > > > I may not fully understand your problem and could be simplifying things > in my head, so feel free to expand. > > > > -- > > Michael > > First of all, thanks for you answer and your attention. > > I know about SELECT. > The idea, here, is to avoid doing POLLING regularly, as it could be easily > a performance nightmare. > The idea is to replace POLLING with PUSH, just like in many cases like > SEDA architecture, or CQRS architecture, or continuous querying with some > data stores. > > So, following this PUSH idea, it would be nice to inform apps connected to > a preferred DC that some new data have been replicated, and is now > "available". > > I hope it's clearer. > > Dominique > > > --001a11c30a045f870904f44176cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You should be able to achieve what you're looking for = with a trigger vs. a modification to the core of Cassandra.

http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-= 0-prototype-triggers-support




On Mon, Mar 10, 2014 at 10:06 AM, DE VITO Dominique <= domin= ique.devito@thalesgroup.com> wrote:
>= On 03/10/2014 07:49 AM, DE VITO Dominique wrote:
> > If I update a data on DC1, I just want apps "connected-first= " to DC2
> > to be informed when this data is available on DC2 after replicati= on.
>
> If I run a SELECT, I'm going to receive the latest data per the re= ad conditions (ONE, TWO, QUORUM), regardless of location of the client conn= ection. If using > network aware topology, you'll get the most curre= nt data in that DC.
>
> > When using Thrift, one way could be to modify CassandraServer cla= ss,
> > to send notification to apps according to data coming in into the=
> > coordinator node of DC2.
> >
> > Is it "common" (~ the way to do it) ?
> >
> > Is there another way to do so ?
> >
> > When using CQL, is there a precise "src code" place to = modify for the
> > same purpose ?
>
> Notifying connected clients about random INSERT or UPDATE statements t= hat ran somewhere seems to be far, far outside the scope of storing data. J= ust configure your client to SELECT in the manner that you need.
>
> I may not fully understand your problem and could be simplifying thing= s in my head, so feel free to expand.
>
> --
> Michael

First of all, thanks for you answer and your attention.

I know about SELECT.
The idea, here, is to avoid doing POLLING regularly, as it could be easily = a performance nightmare.
The idea is to replace POLLING with PUSH, just like in many cases like SEDA= architecture, or CQRS architecture, or continuous querying with some data = stores.

So, following this PUSH idea, it would be nice to inform apps connected to = a preferred DC that some new data have been replicated, and is now "av= ailable".

I hope it's clearer.

Dominique



--001a11c30a045f870904f44176cb--