Ok, I see the you happen to choose the 'right' node idea, but it sounds
like you want to solve C* problems in the client, and they already wrote
that complicated code to make clients simple. You're talking about
reimplementing key-node mappings, network topology (with failures), etc...
Plus, if
A coworker of mine in the UK has been having problems with inserting UTF8
Strings into Cassandra using the Ruby thrift client. I'm just wondering if
anyone else is seeing this or if they have a workaround.
It may have to do with ruby/thrift itself:
Quoting Yang tedd...@gmail.com:
I'd guess that getLong() is not faster because get() probably already benefits
from processor cache etc.
There are two concrete subclasses of ByteBuffer that implement get() -
HeapByteBuffer and DirectByteBuffer (for mapped memory).
It might be possible to
GetLong has to get it a byte at a time still to support endianess.
Id have to think about it, but what you really want is to get it all
into a byte array and then process it in 64bits. AIR there are some
new array recasting things in Java 5+. Ill need to go look at them
more closely...
On Fri,
I'd fetch it all at once into a single byte array and try Arrays.equals()
On Sat, Jul 2, 2011 at 12:45 PM, Jeffrey Kesselman jef...@gmail.com wrote:
GetLong has to get it a byte at a time still to support endianess.
Id have to think about it, but what you really want is to get it all
into a
there is a JIRA completed in 0.7.x that Prefers a certain node in snitch,
so this does roughly what you want MOST of the time
but the problem is that it does not GUARANTEE that the same node will always
be read. I recently read into the HBase vs Cassandra comparison thread that
started after
The way HBase uses ZK (for master election) is not even close to how
Cassandra uses the failure detector.
Using ZK for each operation would (a) not scale and (b) not work
cross-DC for any reasonable latency requirements.
On Sat, Jul 2, 2011 at 11:55 AM, Yang tedd...@gmail.com wrote:
there
Quoting Stephen Connolly stephen.alan.conno...@gmail.com:
All,
As Stephen said, regardless of the transfer protocol, if the content is parsed,
then there is the potential for attacks.
Just to illustrate; the typical injection pattern is:
String user = getUserName()
String cql = select * from
Jonathan:
could you please elaborate more on specifically why they are not even
close?
--- I kind of see what you mean (please correct me if I misunderstood):
Cassandra failure detector
is consulted on every write; while HBase failure detector is only used when
the tablet server joins or leaves.
On Sat, Jul 2, 2011 at 3:57 PM, Yang tedd...@gmail.com wrote:
Jonathan:
could you please elaborate more on specifically why they are not even
close?
--- I kind of see what you mean (please correct me if I misunderstood):
Cassandra failure detector
is consulted on every write; while
Yang, you seem to understand all of the details, at least the details
that have occurred to me, such as having a failure protocol rather than
a perfect failure detector and new leader coordination.
I finally did some more reading outside of Cassandra space and realized
HBase has what I was
On Sat, Jul 2, 2011 at 9:40 AM, Jeremy Hanna jeremy.hanna1...@gmail.com wrote:
It may have to do with ruby/thrift itself:
https://issues.apache.org/jira/browse/THRIFT-1224. Looks like Bryan Duxbury
has an idea of what might help at that level.
That looks like a smoking gun, all right.
You
On 7/2/2011 6:03 AM, William Oberman wrote:
Ok, I see the you happen to choose the 'right' node idea, but it
sounds like you want to solve C* problems in the client, and they
already wrote that complicated code to make clients simple. You're
talking about reimplementing key-node mappings,
On Sat, 2011-07-02 at 19:17 +0100, dnalls...@taz.qinetiq.com wrote:
Just to illustrate; the typical injection pattern is:
String user = getUserName()
String cql = select * from users where KEY='+user+';
execute_cql(cql)
Now, if the user string is obtained from an external source (e.g. web
On Fri, Jun 24, 2011 at 3:58 PM, Philippe watche...@gmail.com wrote:
A) Upon opening an SSTTable for read, Cassandra samples one key in 100 to
speed up disk access.
Close enough.
Is the percentage configurable ?
# The Index Interval determines how large the sampling of row keys
# is for a
15 matches
Mail list logo
