incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Which client API to choose?
Date Mon, 29 Mar 2010 19:40:25 GMT
I went ahead and removed the SP example from that wiki page.

On Wed, Mar 24, 2010 at 1:22 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> Should we just remove that from the wiki, seeing as how we have the
> same (?) sample in contrib/ where it is more likely to be kept up to
> date?
>
> 2010/3/24 Roland Hänel <roland@haenel.me>:
>> 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<RowMutation> ml = new Stack<RowMutation>();
>>                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 <eevans@rackspace.com>
>>>
>>> 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
>>> (https://issues.apache.org/jira/browse/CASSANDRA).
>>>
>>>
>>> --
>>> Eric Evans
>>> eevans@rackspace.com
>>>
>>
>>
>

Mime
View raw message