Hi All,
I am using cassandra 2.1.3 , we have an application written in .net for
that we are using DataStax .Net Drivers . We are deploying this to our
production server (the .Net application) , we have created a static route
from our .net Webserver to the cassandra Cluster on port 9042 .
The Webse
if already fixed, my use case is wrong. But I think it's very normal case.
2015-08-28 10:57 GMT+08:00 joseph gao :
> I don't understand, does the issue mean 'don't use wildcard' or 'already
> fixed'?
>
> 2015-08-26 15:16 GMT+08:00 Peer, Oded :
>
>> See https://issues.apache.org/jira/browse/CASSAN
I don't understand, does the issue mean 'don't use wildcard' or 'already
fixed'?
2015-08-26 15:16 GMT+08:00 Peer, Oded :
> See https://issues.apache.org/jira/browse/CASSANDRA-7910
>
>
>
>
>
> *From:* joseph gao [mailto:gaojf.bok...@gmail.com]
> *Sent:* Wednesday, August 26, 2015 6:15 AM
> *To:* u
Even if the data were absolutely evenly distributed, that won't guarantee
that the hash values of the partition keys used in your client queries
won't collide a result in a hotspot.
Another possibility is that your data is not partitioned well at the
primary key level. Are you using clustering key
Hi,
Did you try to run the following on all your nodes and compare ?
du -sh /*whatever*/cassandra/data/*
Of course if you have unequal snapshots sizes remove them in the above
command (or directly remove them).
This should answer (barely) your question about an eventual even
distribution (/!\ h
Is there a way to find out how data is distributed within column family by each
node? Nodetool provides how data is distributed across nodes that only shows
all the data by node. We are seeing heavy load on one node and I suspect that
partitioning is not distributing data equally. But to prove t
Hi All,
I am using cassandra 2.1.3 , we have an application written in .net for
that we are using DataStax .Net Drivers . We are deploying this to our
production server (the .Net application) , we have created a static route
from our .net Webserver to the cassandra Cluster on port 9042 .
The Webse
Step 10 is wrong
N3, N4 and N5 have accepted ballot from N2 which is higher than ballot from
N1 so N3, N4 and N5 should reject request at step 9)
The fact that there is an extra round trip for Read/Result at steps 5) to
8) does not matter and does not interfere with the correctness of the Paxos
P
Hi Sylvain and all folks,
I have another scenario in my mind where *linearizable consistency (CAS,
Compare-and-Set) *can fail as we *the following round-trips:*
*1.* *Prepare/promise*
*2.* *Read/result*
*3.* *Propose/accept*
4. *Commit/acknowledgment *
Assume we have an ap
