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.
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
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>();
but it doesn't quite work out until now (however, also doesn't throw
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... ;-)
On Wed, 2010-03-24 at 14:15 +0100, Roland Hänel wrote:Right, using raw Thrift means that you're interacting with the system by
> Still, I'm somewhat confused which API to choose if I was heading for
> 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.
calling the RPC methods directly. You've got maximum flexibility but
you're quickly going to notice a lot of boiler plate accumulating.
The "best choice" is always going to be subjective, but Hector has
> 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
> with Cassandra?
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.
The fat client is different from Thrift in that it obtains a sort of
> 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.
> 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
> bulk jobs but not for the "everyday Java client program"?
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