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...
Plu
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:
https://issues.apache.org/jira/browse/THRIFT-
Quoting Yang :
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 optimise the comparison
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 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 byte array an
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 F
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 wrote:
> there is a JIRA completed in
Quoting Stephen Connolly :
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 users where KEY='"+user+"';"
exe
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 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 HBase failure
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 ask
On Sat, Jul 2, 2011 at 9:40 AM, Jeremy Hanna 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 can always use binary fi
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 mapping
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
On Fri, Jun 24, 2011 at 3:58 PM, Philippe 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 given SSTable. The
15 matches
Mail list logo
