I found the problem.
jira ticket :
https://issues.apache.org/jira/browse/CASSANDRA-8081
2014-10-06 18:45 GMT+02:00 Kais Ahmed :
> Hi all,
>
> I'm a bit stuck , i want to expand my cluster C* 2.0.6 but i encountered
> an error on
> the new node.
>
> ERROR [FlushWriter:2] 2014-10-06 16:15:35,147 C
Hi, All,
I'm trying to enable client-to-node encrypt communication in Cassandra (2.0.7)
with Astyanax client library (version=1.56.48)
I found the links about how to enable this feature:
http://www.datastax.com/documentation/cassandra/2.0/cassandra/security/secureSSLClientToNode_t.html
But this
Hi Tyler,
I tried the configuration that you said and it didn’t work. I’m going to
explain our scenario and the configurations that we tried but that didn’t work.
We work with VMWare virtual machines and we need to configure a 3 node cluster
of Cassandra. We configure the file cassandra.yaml wit
Haven't personally followed this but give it a go:
http://lyubent.github.io/security/planetcassandra/2013/05/31/ssl-for-astyanax.html
On 8 October 2014 20:46, Lu, Boying wrote:
> Hi, All,
>
>
>
> I’m trying to enable client-to-node encrypt communication in Cassandra
> (2.0.7) with Astyanax clien
On Wed, Oct 8, 2014 at 5:20 AM, Ricard Mestre Subirats <
ricard.mestre.subir...@everis.com> wrote:
> At the machine with IP 192.168.150.112:
>
> -cluster_name: 'CassandraCluster1'
>
> -seeds: "192.168.150.112"
>
> -listen_address: 192.168.150.112
>
> -rpc_address: 0.0.0.0
>
> -broadcast_rpc_addres
Hi -
We are running a small 3-node cassandra cluster on Google Compute Engine.
I notice that our machines are reporting (via a collectd agent, confirmed
by `top`) a significant amount of cpu time in the NICE state. For example,
one of our machines is a n1-highmem-4 (4 cores, 26 GB RAM). Here is
Hello,
AFAIK Compaction threads run with a lower affinity, I believe that will show up
as "niced"..
Regards,
Andras
From: Ian Rose mailto:ianr...@fullstory.com>>
Reply-To: user mailto:user@cassandra.apache.org>>
Date: Wednesday 8 October 2014 17:29
To: user mailto:user@cassandra.apache.org>>
Su
Hello,
I was wondering if anyone (Datastax?) has any usage data about
consistency levels. For example, what consistency levels are real
applications using in real production scenarios. Who is using eventual
consistency (ONE-ONE) in production vs strong consistency
(QUORUM-QUORUM, ONE-ALL). Ob
One should be carefull about using ALL consistency because by doing so, you
sacrify the high availability (loosing one node of the replica prevent you
from writing/reading with ALL). Lots of people choose Cassandra for high
availability so using ALL is kind of showstopper.
Of course there are spe
I would definitely use dynamic columns for this instead of modifying schema
(dynamically).
Sounds like an anti-pattern to me.
From: toddf...@gmail.com [mailto:toddf...@gmail.com] On Behalf Of Todd Fast
Sent: Monday, October 06, 2014 11:57 PM
To: Cassandra Users
Subject: Dynamic schema modificat
Nope. No secondary index. Just a slice query on the PK.
On Tuesday, October 7, 2014, Robert Coli wrote:
> On Tue, Oct 7, 2014 at 3:11 PM, Owen Kim > wrote:
>
>> Sigh, it is a bit grating. I (genuinely) appreciate your acknowledgement
>> of that. Though, I didn't intend for the question to be
On Wed, Oct 8, 2014 at 9:27 AM, William Katsak
wrote:
> I was wondering if anyone (Datastax?) has any usage data about consistency
> levels. For example, what consistency levels are real applications using in
> real production scenarios. Who is using eventual consistency (ONE-ONE) in
> production
Ah, thanks Andras.
Running `ps -T` I do in fact seen that most Cassandra threads have priority
0 but a few are at priority 4 and these also show non-trivial pcpu. So
that seems like it!
- Ian
On Wed, Oct 8, 2014 at 11:56 AM, Andras Szerdahelyi <
andras.szerdahe...@ignitionone.com> wrote:
> H
I don't know of any such data collected by DataStax - it's not like we're
the NSA, sniffing all requests.
ONE is certainly fast, but only fine if you don't have immediate need to
read the data or don't need the absolutely most recent value.
To be clear, even QUORUM write is eventual consisten
Thanks.
I am thinking more in terms of the combination of read/write. If I am
correct, QUORUM reads and QUORUM writes (or ONE-ALL) should deliver
strong consistency in the absence of failures, correct? Or this this
still considered eventual consistency, somehow?
-Bill
On 10/08/2014 06:17 P
It would certainly depend on the nuances of your definitions! Especially
since you added this monster of a caveat: " in the absence of failures".
Here's a scenario for you: 1) Write at quorum, 2) Add 3 nodes, 3)
Immediately read at [the new] quorum - no guarantee that the new nodes will
have f
17 matches
Mail list logo
