> Has anyone else seen nodes "hang" for several seconds like this? I'm
> not sure if this is a Java VM issue (e.g. garbage collection) or something
Since garbage collection is logged (if you're running with default
settings etc), any multi-second GC:s should be discoverable in said
log. So for te
On Tue, Jul 6, 2010 at 6:00 PM, Jonathan Ellis wrote:
> Because stateful keyspace is semantically closer to how people use it:
Hmm no other reason?
Writing a client-side wrapper which turns
get(key, column_path, clevel) into
get(@keyspace, key, column_path, clevel)
is trivial in pretty much an
Greetings Cassandra Developers!
We've been trying to benchmark Cassandra performance and have
developed a test client written in C++ that uses multiple threads to
send out a large number of write and read requests (as fast as the
server can handle them).
One of the results we're seeing is a
Because stateful keyspace is semantically closer to how people use it:
one keyspace per application.
If Thrift allowed us to make the keyspace-per-method-call optional we
could go that route, but it does not.
On Tue, Jul 6, 2010 at 10:56 AM, Thomas Heller wrote:
> Hey,
>
> I wonder if there is a
Hey,
I wonder if there is any particular reasoning why the API
(thrift/avro) will become stateful in 0.7? Granted it already is doing
that for "login", but why is the keyspace argument moved to a stateful
level?
I wrote a ruby client to help me in my app development and while it
currently just co
