Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 50121 invoked from network); 24 Mar 2010 17:17:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Mar 2010 17:17:48 -0000 Received: (qmail 13716 invoked by uid 500); 24 Mar 2010 17:17:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 13700 invoked by uid 500); 24 Mar 2010 17:17:47 -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 13692 invoked by uid 99); 24 Mar 2010 17:17:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Mar 2010 17:17:47 +0000 X-ASF-Spam-Status: No, hits=3.7 required=10.0 tests=AWL,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of roland237@googlemail.com designates 209.85.220.216 as permitted sender) Received: from [209.85.220.216] (HELO mail-fx0-f216.google.com) (209.85.220.216) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Mar 2010 17:17:42 +0000 Received: by fxm8 with SMTP id 8so3289678fxm.25 for ; Wed, 24 Mar 2010 10:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=7IjNibErX2e/BQZrfJxoGutp6lf4jD2b3lD6tlkMlKM=; b=A+PGDZ0rwyYb/A8UphOVFvvTkGGaoFLOAmEniSSC2D+WxDdAVlfRTDe0AwHUyzHlG+ Lh587VW1Zk7yNZNDxSLbuEi8VHLzzgNG+syqF18z2zkvpAdf/GE+dnsQdv0yPA6Vnmmm 4GqZJbQZ7wS8Cogvc/gid6Xn6/DHULuiNUZlg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=OwgnhS3vfZUgcIvSWvNvlz9/rFkihLPlztG31SIbEXWpP3lmAQXoYwPzgP06qFgTiO FZRfbgemg0NjCX0lZUqGmqhLjcqBOd9DLrLHCfOhwgE1eCZWWZcVyplwCdnFpFncgf9n aMxetfv72ZxkusqyUOACJlEImE0EdhNoFGlHE= MIME-Version: 1.0 Sender: roland237@googlemail.com Received: by 10.223.63.208 with SMTP id c16mr6476569fai.29.1269451040636; Wed, 24 Mar 2010 10:17:20 -0700 (PDT) In-Reply-To: <1269445120.2545.128.camel@erebus.lan> References: <429591151003240615r796fd79bp213f0dfd5105c203@mail.gmail.com> <1269445120.2545.128.camel@erebus.lan> Date: Wed, 24 Mar 2010 18:17:20 +0100 X-Google-Sender-Auth: 226ad3116fbf76da Message-ID: <429591151003241017g5ccb3ba9j745682616f7c4c5@mail.gmail.com> Subject: Re: Which client API to choose? From: =?ISO-8859-1?Q?Roland_H=E4nel?= To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001517440fb656555304828f1ac3 --001517440fb656555304828f1ac3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks a lot for these suggestions. My fat client issues came mainly from the fact that the Wiki example ( http://wiki.apache.org/cassandra/ClientExamples) just doesn't work with 0.6.0beta3. - StorageService.instance() does not work because instance is a static variable, not a method - new ColumnPatch("Standard1", null, ("colb").getBytes()) does not work because there is no such constructor signature defined; use new ColumnPath("Standard1").setColumn("colb".getBytes()) instead - StorageProxy.insert(change) does not work, because there is no such method (static or dynamic) in this class, I started to look around and came up with something like List ml =3D new Stack(); ml.add(change); StorageProxy.mutate(ml); but it doesn't quite work out until now (however, also doesn't throw an exception). Please don't shoot me, I came up with this code just grep'ing the source and doing something that seemed to make a little sense... ;-) Greetings, Roland 2010/3/24 Eric Evans > On Wed, 2010-03-24 at 14:15 +0100, Roland H=E4nel wrote: > > Still, I'm somewhat confused which API to choose if I was heading for > > a > > bigger project > > > > 1. plain Thrift (for Java)? > > Seems the major advantage is that Thrift is available in many > > languages, but > > if I'm only interested in Java that doesn't give me much. The Java > > code on > > the native Thrift interface looks quite awful. It also seems to me as > > if it > > would result in many lines of code even for quite trivial jobs. > > Right, using raw Thrift means that you're interacting with the system by > calling the RPC methods directly. You've got maximum flexibility but > you're quickly going to notice a lot of boiler plate accumulating. > > > 2. a higher level Java Client? > > I didn't look at Hector right now, however it confused me somewhat > > that if > > something like Hector was the "best choice", why isn't this then > > bundled > > with Cassandra? > > The "best choice" is always going to be subjective, but Hector has > developed a lot of momentum in a short period of time. It would not be > at all unreasonable to call it the de facto Java library for Cassandra. > > As for why it's not bundled, that is a feature and not a bug. As > separate projects the two can move at their own pace, use the work-flow > of their own choosing, pick the tools right for them, and add committers > without the unwanted additional oversight. > > IMO, bundling Hector wouldn't enhance it's development, (if anything, it > would inhibit it), and by sending the message that it was the One True > Library it would unnecessarily close the door on competition. > > > 3. the "native Java fat Client" > > I started some experiments with it, however couldn't get it completely > > working, documentation in the Wiki is not really usuable at all. > > Question > > would be if this is something that you (the developers) consider as > > the "big > > thing for the future" or is this some niche for lets say high > > performance > > bulk jobs but not for the "everyday Java client program"? > > The fat client is different from Thrift in that it obtains a sort of > limited membership in the cluster and is able to route requests directly > to nodes, as opposed to the proxying that can occur when you make a > Thrift call to a random node. > > The fat client is not as well tested, and it's true that we usually > steer people toward Thrift unless they have specific requirements. If > you're having problems though, we'd love to hear about them, either > here, or in a bug report > (https://issues.apache.org/jira/browse/CASSANDRA). > > > -- > Eric Evans > eevans@rackspace.com > > --001517440fb656555304828f1ac3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks a lot for these suggestions.

My fat client issues came mainly= from the fact that the Wiki example (http://wiki.apache.org/cassandra/ClientExamples)= just doesn't work with 0.6.0beta3.

=A0 - StorageService.instance()
=A0=A0=A0 does not work because ins= tance is a static variable, not a method

=A0 - =A0=A0 new ColumnPatc= h("Standard1", null, ("colb").getBytes())
=A0=A0=A0= does not work because there is no such constructor signature defined; use =
=A0 =A0 =A0=A0 new ColumnPath("Standard1").setColumn("colb&q= uot;.getBytes())
=A0=A0=A0 instead

=A0 -=A0=A0=A0=A0 StorageProxy= .insert(change)
=A0=A0=A0 does not work, because there is no such method= (static or dynamic) in this
=A0=A0=A0 class, I started to look around and came up with something like=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 List<RowMutation> ml =3D= new Stack<RowMutation>();
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ml.add(change);
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 StoragePr= oxy.mutate(ml);
=A0=A0=A0 but it doesn't quite work out until now (however, also doesn&= #39;t throw
=A0=A0=A0 an exception).
=A0=A0=A0 Please don't shoot= me, I came up with this code just grep'ing the
=A0=A0=A0 source and= doing something that seemed to make a little sense... ;-)

Greetings,
Roland


2010/3/24 Er= ic Evans <eeva= ns@rackspace.com>
On Wed, 2010-03-24 at 14:15 +0100, Roland H=E4nel wrote:<= br> > Still, I'm somewhat confused which API to choose if I was heading = for
> a
> bigger project
>
> 1. plain Thrift (for Java)?
> Seems the major advantage is that Thrift is available in many
> languages, but
> if I'm only interested in Java that doesn't give me much. The = Java
> code on
> the native Thrift interface looks quite awful. It also seems to me as<= br> > if it
> would result in many lines of code even for quite trivial jobs.

Right, using raw Thrift means that you're interacting with the sy= stem by
calling the RPC methods directly. You've got maximum flexibility but you're quickly going to notice a lot of boiler plate accumulating.

> 2. a higher level Java Client?
> I didn't look at Hector right now, however it confused me somewhat=
> that if
> something like Hector was the "best choice", why isn't t= his then
> bundled
> with Cassandra?

The "best choice" is always going to be subjective, but Hec= tor has
developed a lot of momentum in a short period of time. It would not be
at all unreasonable to call it the de facto Java library for Cassandra.

As for why it's not bundled, that is a feature and not a bug. As
separate projects the two can move at their own pace, use the work-flow
of their own choosing, pick the tools right for them, and add committers without the unwanted additional oversight.

IMO, bundling Hector wouldn't enhance it's development, (if anythin= g, it
would inhibit it), and by sending the message that it was the One True
Library it would unnecessarily close the door on competition.

> 3. the "native Java fat Client"
> I started some experiments with it, however couldn't get it comple= tely
> working, documentation in the Wiki is not really usuable at all.
> Question
> would be if this is something that you (the developers) consider as > the "big
> thing for the future" or is this some niche for lets say high
> performance
> bulk jobs but not for the "everyday Java client program"?
The fat client is different from Thrift in that it obtains a sort of<= br> limited membership in the cluster and is able to route requests directly to nodes, as opposed to the proxying that can occur when you make a
Thrift call to a random node.

The fat client is not as well tested, and it's true that we usually
steer people toward Thrift unless they have specific requirements. If
you're having problems though, we'd love to hear about them, either=
here, or in a bug report
(https://issues.apache.org/jira/browse/CASSANDRA).


--
Eric Evans
eevans@rackspace.com


--001517440fb656555304828f1ac3--