cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Hänel <>
Subject Re: Which client API to choose?
Date Wed, 24 Mar 2010 17:17:20 GMT
Thanks a lot for these suggestions.

My fat client issues came mainly from the fact that the Wiki example ( just doesn't work with

  - 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;
       new ColumnPath("Standard1").setColumn("colb".getBytes())

  -     StorageProxy.insert(change)
    does not work, because there is no such method (static or dynamic) in
    class, I started to look around and came up with something like
               List<RowMutation> ml = new Stack<RowMutation>();
    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... ;-)


2010/3/24 Eric Evans <>

> On Wed, 2010-03-24 at 14:15 +0100, Roland Hänel 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
> (
> --
> Eric Evans

View raw message