Re: Changing Racks of Nodes

[Ben Bromhead]

If the rack as defined in Cassandra stays the same (e.g.
cassandra-rackdc.properties), things will keep working as expected...
except when the actual rack (or fault domain) goes down and you are likely
to lose more nodes than expected.

If you change the rack as defined in Cassandra, the node will start
handling queries it does not have data for.

The best way to change the move racks is to decommission the node, then
bootstrap it with the new rack settings.

On Wed, 20 Apr 2016 at 15:49 Anubhav Kale 
wrote:

> Hello,
>
>
>
> If a running node moves around and changes its rack in the process, when
> its back in the cluster (through ignore-rack property), is it a correct
> statement that queries will not see some data residing on this node until a
> repair is run ?
>
>
>
> Or, is it more like the node may get requests for the data it does not own
> (meaning data will never “disappear”) ?
>
>
>
> I’d appreciate some details on this topic from experts !
>
>
>
> Thanks !
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer

Changing Racks of Nodes

[Anubhav Kale]

Hello,

If a running node moves around and changes its rack in the process, when its 
back in the cluster (through ignore-rack property), is it a correct statement 
that queries will not see some data residing on this node until a repair is run 
?

Or, is it more like the node may get requests for the data it does not own 
(meaning data will never "disappear") ?

I'd appreciate some details on this topic from experts !

Thanks !

Re: When are hints written?

[Vinu Thomas]

how do you unsubscribe



From: Bo Finnerup Madsen 
Sent: Wednesday, April 20, 2016 9:38 AM
To: user@cassandra.apache.org
Subject: When are hints written?

Hi,

We have a small 5 node cluster of m4.xlarge clients that receives writes from 
~20 clients. The clients will write as fast as they can, and the whole process 
is limited by the write performance of the cassandra cluster.
After we have tweaked our schema to avoid large partitions, the load is going 
ok and we don't see any warnings or errors in the cassandra logs. But we do see 
quite a lot of hint handoff activity. During the load, the cassandra nodes are 
quite loaded, with linux reporting a load as high as 20.

I have read the available documentation on how hints works, and to my 
understanding hints should only be written if a node is down. But as far as I 
can see, none of the nodes are marked as down during the load. So I suspect I 
am missing something :)
We have configured the servers with write_request_timeout_in_ms: 12 and the 
clients with a timeout of 13, but still get hints stored.

In our case, I would like for the cluster to wait for the write to be persisted 
on the relevant nodes before returning an ok to the client. But I don't know 
which knobs to turn to accomplish this? or if it is even possible :)

We are running cassandra 3.0.3, with 8Gb heap and a replication factor of 3.

Thank you in advance!

Yours sincerely,
  Bo Madsen

Re: nodetool -h fails Connection refused

[Alaa Zubaidi (PDF)]

Thanks Nate...
It works now..

On Wed, Apr 20, 2016 at 8:05 AM, Nate McCall  wrote:

> You need to set LOCAL_JMX=false
>
> It will then read the rest of this stanza:
>
> https://github.com/apache/cassandra/blob/cassandra-2.2/conf/cassandra-env.sh#L284-L288
>
> Using the defaults above as-is, you will need to add JMX authentication.
> Details are here:
>
> https://docs.datastax.com/en/cassandra/2.2/cassandra/configuration/secureNodetoolSSL.html
>
> A lot of this can be controlled with system properties as well:
> http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
>
> The default config files for JMX authentication and access included in the
> JVM also have extensive details in the comments:
> $JAVA_HOME/jre/lib/management/jmxremote.access
> $JAVA_HOME/jre/lib/management/jmxremote.password.template
>
>
>
> On Tue, Apr 19, 2016 at 8:40 PM, Alaa Zubaidi (PDF) 
> wrote:
>
>> Hi,
>>
>> I am trying to run nodetool remotely. but its not working:
>> I am running Cassandra 2.2.5 on CentOS 6.
>> listen_address: is set to 
>> rpc_address: is set to 0.0.0.0
>> broadcast_rpc_address: is set to 
>>
>> I changed the following in cassadnra-env.sh
>> JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname="
>> -Dcom.sun.management.jmxremote.port=7199
>> -Dcom.sun.management.jmxremote.ssl=false
>> -Dcom.sun.management.jmxremote.authenticate=false
>>
>> "nodetool -h  -p  status" results in:
>> failed to connect to 'hostname' - Connection Exception: 'Connection
>> refused"
>>
>> netstat -nl | grep 7199
>> tcp00127.0.0.1:71990.0.0.0:*LISTEN
>>
>> ONLY "nodetool -h localhost" works
>>
>> Any idea how to fix it?
>>
>> Thanks,
>> Alaa
>>
>>
>> *This message may contain confidential and privileged information. If it
>> has been sent to you in error, please reply to advise the sender of the
>> error and then immediately permanently delete it and all attachments to it
>> from your systems. If you are not the intended recipient, do not read,
>> copy, disclose or otherwise use this message or any attachments to it. The
>> sender disclaims any liability for such unauthorized use. PLEASE NOTE that
>> all incoming e-mails sent to PDF e-mail accounts will be archived and may
>> be scanned by us and/or by external service providers to detect and prevent
>> threats to our systems, investigate illegal or inappropriate behavior,
>> and/or eliminate unsolicited promotional e-mails (“spam”). If you have any
>> concerns about this process, please contact us at *
>> *legal.departm...@pdf.com* *.*
>
>
>
>
> --
> -
> Nate McCall
> Austin, TX
> @zznate
>
> Co-Founder & Sr. Technical Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>



-- 

Alaa Zubaidi
PDF Solutions, Inc.
333 West San Carlos Street, Suite 1000
San Jose, CA 95110  USA
Tel: 408-283-5639
fax: 408-938-6479
email: alaa.zuba...@pdf.com

-- 
*This message may contain confidential and privileged information. If it 
has been sent to you in error, please reply to advise the sender of the 
error and then immediately permanently delete it and all attachments to it 
from your systems. If you are not the intended recipient, do not read, 
copy, disclose or otherwise use this message or any attachments to it. The 
sender disclaims any liability for such unauthorized use. PLEASE NOTE that 
all incoming e-mails sent to PDF e-mail accounts will be archived and may 
be scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”). If you have any 
concerns about this process, please contact us at *
*legal.departm...@pdf.com* *.*

Re: A few misbehaving nodes

[Patrick McFadin]

Can you show the output of a tpstats on one of the effected nodes? That
will give some indication where the trouble might be.

Patrick

On Tue, Apr 19, 2016 at 6:54 AM, sai krishnam raju potturi <
pskraj...@gmail.com> wrote:

> hi;
>do we see any hung process like Repairs on those 3 nodes?  what does
> "nodetool netstats" show??
>
> thanks
> Sai
>
> On Tue, Apr 19, 2016 at 8:24 AM, Erik Forsberg  wrote:
>
>> Hi!
>>
>> I have this problem where 3 of my 84 nodes misbehave with too long GC
>> times, leading to them being marked as DN.
>>
>> This happens when I load data to them using CQL from a hadoop job, so
>> quite a lot of inserts at a time. The CQL loading job is using
>> TokenAwarePolicy with fallback to DCAwareRoundRobinPolicy. Cassandra java
>> driver version 2.1.7.1 is in use.
>>
>> My other observation is that around the time the GC starts to work like
>> crazy, there is a lot of outbound network traffic from the troublesome
>> nodes. If a healthy node has around 25 Mbit/s in, 25 Mbit/s out, an
>> unhealthy sees 25 Mbit/s in, 200 Mbit/s out.
>>
>> So, something is iffy with these 3 nodes, but I have some trouble finding
>> out exactly what makes them differ.
>>
>> This is Cassandra 2.0.13 (yes, old) using vnodes. Keyspace is using
>> NetworkTopologyStrategy with replication 2, in one datacenter.
>>
>> One thing I know I'm doing wrong is that I have slightly differing number
>> of hosts in each of my 6 chassies (One of them have 15 nodes, one of have
>> 13, the remaining have 14). Could what I'm seeing here be the effect of
>> that?
>>
>> Other ideas on what could be wrong? Some kind of vnode imbalance? How can
>> I diagnose that? What metrics should I be looking at?
>>
>> Thanks,
>> \EF
>>
>>
>>
>

Limit 1

[Jimmy Lin]

I have a following table(using default sized tier compaction) that its column 
get TTLed every hour(as we want to keep only the last 1 hour events)

And I do
Select * from mytable where object_id = ‘’ LIMIT 1;

And since query only interested in last/latest value, will cassandra need to 
scan multiple sstables or potentially skipping tombstones data just to get the 
top of the latest data?
Or is it smart enough to know the beginning of the sstables and get the result 
very efficiently?


CREATE TABLE mytable (
    object_id text,
    created timeuuid,
    my_data text
    PRIMARY KEY (object_id, created)
) WITH CLUSTERING ORDER BY (created DESC)

Re: Cassandra causing OOM Killer to strike on new cluster running 3.4

[Satoshi Hikida]

Hi, Paulo

Thank you for your help!

I'll try to use it.

Regards,
Satoshi

On Wed, Apr 20, 2016 at 8:43 PM, Paulo Motta 
wrote:

> 2.2.6 should be released in the next couple of weeks, but I also attached
> a patch file to the issue if you want to patch 2.2.5 manually.
>
> 2016-04-20 0:19 GMT-03:00 Satoshi Hikida :
>
>> Hi,
>>
>> I'm looking forward to a  patch (file) for this bug(CASSANDRA-11344) to
>> apply C* version 2.2.5. Is there available patch for that version? I
>> watched link(https://issues.apache.org/jira/browse/CASSANDRA-11344) but
>> couldn't find patch file or something like that.  Or is there any
>> workaround to avoid this bug with version 2.2.5?
>>
>> Regards,
>> Satoshi
>>
>> On Tue, Mar 15, 2016 at 4:47 AM, Adam Plumb  wrote:
>>
>>> OK so good news, I'm running with the patched jar file in my cluster and
>>> haven't seen any issues.  The bloom filter off-heap memory usage is between
>>> 1.5GB and 2GB per node, which is much more in-line with what I'm expecting!
>>>  (thumbsup)
>>>
>>> On Mon, Mar 14, 2016 at 9:42 AM, Adam Plumb  wrote:
>>>
 Thanks for the link!  Luckily the cluster I'm running is not yet in
 production and running with dummy data so I will throw that jar on the
 nodes and I'll let you know how things shake out.

 On Sun, Mar 13, 2016 at 11:02 PM, Paulo Motta  wrote:

> You could be hitting CASSANDRA-11344 (
> https://issues.apache.org/jira/browse/CASSANDRA-11344).  If that's
> the case, you may try to replace your cassandra jar on an affected node
> with a version with this fix in place and force bloom filter regeneration
> to see if if it fixes your problem. You can build with "ant jar" from this
> branch: https://github.com/pauloricardomg/cassandra/tree/3.4-11344
>
> You can force bloom filter regeneration by either removing your
> *Filter.db files (make sure to backup them before for safety) or changing
> the bloom_filter_fp_chance before restarting affected nodes with the fixed
> jar.
>
> 2016-03-13 19:51 GMT-03:00 Adam Plumb :
>
>> So it's looking like the bloom filter off heap memory usage is
>> ramping up and up until the OOM killer kills the java process.  I
>> relaunched on instances with 60GB of memory and the same thing is
>> happening.  A node will start using more and more RAM until the process 
>> is
>> killed, then another node will start using more and more until it is also
>> killed.
>>
>> Is this the expected behavior?  It doesn't seem ideal to me.  Is
>> there anything obvious that I'm doing wrong?
>>
>> On Fri, Mar 11, 2016 at 11:31 AM, Adam Plumb 
>> wrote:
>>
>>> Here is the creation syntax for the entire schema.  The xyz table
>>> has about 2.1 billion keys and the def table has about 230 million keys.
>>> Max row size is about 3KB, mean row size is 700B.
>>>
>>> CREATE KEYSPACE abc WITH replication = {'class':
 'NetworkTopologyStrategy', 'us-east': 3};
 CREATE TABLE xyz (
   id text,
   secondary_id int,
   data text,
   PRIMARY KEY(id)
 )
   WITH
   compaction = { 'class': 'LeveledCompactionStrategy' }
   and compression = {'class': 'LZ4Compressor'};
 CREATE INDEX secondary_id_index ON abc.xyz (secondary_id);
 CREATE TABLE def (
   id text,
   secondary_id int,
   data text,
   PRIMARY KEY(id)
 )
   WITH
   compaction = { 'class': 'LeveledCompactionStrategy' }
   and compression = {'class': 'LZ4Compressor'};
 CREATE INDEX secondary_id_index_def ON abc.def (secondary_id);
>>>
>>>
>>> On Fri, Mar 11, 2016 at 11:24 AM, Jack Krupansky <
>>> jack.krupan...@gmail.com> wrote:
>>>
 What is your schema and data like - in particular, how wide are
 your partitions (number of rows and typical row size)?

 Maybe you just need (a lot) more heap for rows during the repair
 process.

 -- Jack Krupansky

 On Fri, Mar 11, 2016 at 11:19 AM, Adam Plumb 
 wrote:

> These are brand new boxes only running Cassandra.  Yeah the kernel
> is what is killing the JVM, and this does appear to be a memory leak 
> in
> Cassandra.  And Cassandra is the only thing running, aside from the 
> basic
> services needed for Amazon Linux to run.
>
> On Fri, Mar 11, 2016 at 11:17 AM, Sebastian Estevez <
> sebastian.este...@datastax.com> wrote:
>
>> Sacrifice child in dmesg is your OS killing the process with the
>> most ram. That means you're actually running out of memory at the 
>> Linux

Re: When are hints written?

[Jens Rantil]

Hi Bo,

> In our case, I would like for the cluster to wait for the write to be
persisted on the relevant nodes before returning an ok to the client. But I
don't know which knobs to turn to accomplish this? or if it is even
possible :)

This is what write consistency option is for. Have a look at
https://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html.
Note, however that if you use ALL, your clients will fail (throw exception,
depending on language) as soon as a single partition can't be written. This
means you can't do online maintenance of a Cassandra node (such as
upgrading it etc.) without experiencing write issues.

Cheers,
Jens

On Wed, Apr 20, 2016 at 3:39 PM Bo Finnerup Madsen 
wrote:

> Hi,
>
> We have a small 5 node cluster of m4.xlarge clients that receives writes
> from ~20 clients. The clients will write as fast as they can, and the whole
> process is limited by the write performance of the cassandra cluster.
> After we have tweaked our schema to avoid large partitions, the load is
> going ok and we don't see any warnings or errors in the cassandra logs. But
> we do see quite a lot of hint handoff activity. During the load, the
> cassandra nodes are quite loaded, with linux reporting a load as high as 20.
>
> I have read the available documentation on how hints works, and to my
> understanding hints should only be written if a node is down. But as far as
> I can see, none of the nodes are marked as down during the load. So I
> suspect I am missing something :)
> We have configured the servers with write_request_timeout_in_ms: 12
> and the clients with a timeout of 13, but still get hints stored.
>
> In our case, I would like for the cluster to wait for the write to be
> persisted on the relevant nodes before returning an ok to the client. But I
> don't know which knobs to turn to accomplish this? or if it is even
> possible :)
>
> We are running cassandra 3.0.3, with 8Gb heap and a replication factor of
> 3.
>
> Thank you in advance!
>
> Yours sincerely,
>   Bo Madsen
>
-- 

Jens Rantil
Backend Developer @ Tink

Tink AB, Wallingatan 5, 111 60 Stockholm, Sweden
For urgent matters you can reach me at +46-708-84 18 32.

Re: nodetool -h fails Connection refused

[Nate McCall]

You need to set LOCAL_JMX=false

It will then read the rest of this stanza:
https://github.com/apache/cassandra/blob/cassandra-2.2/conf/cassandra-env.sh#L284-L288

Using the defaults above as-is, you will need to add JMX authentication.
Details are here:
https://docs.datastax.com/en/cassandra/2.2/cassandra/configuration/secureNodetoolSSL.html

A lot of this can be controlled with system properties as well:
http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html

The default config files for JMX authentication and access included in the
JVM also have extensive details in the comments:
$JAVA_HOME/jre/lib/management/jmxremote.access
$JAVA_HOME/jre/lib/management/jmxremote.password.template



On Tue, Apr 19, 2016 at 8:40 PM, Alaa Zubaidi (PDF) 
wrote:

> Hi,
>
> I am trying to run nodetool remotely. but its not working:
> I am running Cassandra 2.2.5 on CentOS 6.
> listen_address: is set to 
> rpc_address: is set to 0.0.0.0
> broadcast_rpc_address: is set to 
>
> I changed the following in cassadnra-env.sh
> JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname="
> -Dcom.sun.management.jmxremote.port=7199
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=false
>
> "nodetool -h  -p  status" results in:
> failed to connect to 'hostname' - Connection Exception: 'Connection
> refused"
>
> netstat -nl | grep 7199
> tcp00127.0.0.1:71990.0.0.0:*LISTEN
>
> ONLY "nodetool -h localhost" works
>
> Any idea how to fix it?
>
> Thanks,
> Alaa
>
>
> *This message may contain confidential and privileged information. If it
> has been sent to you in error, please reply to advise the sender of the
> error and then immediately permanently delete it and all attachments to it
> from your systems. If you are not the intended recipient, do not read,
> copy, disclose or otherwise use this message or any attachments to it. The
> sender disclaims any liability for such unauthorized use. PLEASE NOTE that
> all incoming e-mails sent to PDF e-mail accounts will be archived and may
> be scanned by us and/or by external service providers to detect and prevent
> threats to our systems, investigate illegal or inappropriate behavior,
> and/or eliminate unsolicited promotional e-mails (“spam”). If you have any
> concerns about this process, please contact us at *
> *legal.departm...@pdf.com* *.*




-- 
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

When are hints written?

[Bo Finnerup Madsen]

Hi,

We have a small 5 node cluster of m4.xlarge clients that receives writes
from ~20 clients. The clients will write as fast as they can, and the whole
process is limited by the write performance of the cassandra cluster.
After we have tweaked our schema to avoid large partitions, the load is
going ok and we don't see any warnings or errors in the cassandra logs. But
we do see quite a lot of hint handoff activity. During the load, the
cassandra nodes are quite loaded, with linux reporting a load as high as 20.

I have read the available documentation on how hints works, and to my
understanding hints should only be written if a node is down. But as far as
I can see, none of the nodes are marked as down during the load. So I
suspect I am missing something :)
We have configured the servers with write_request_timeout_in_ms: 12 and
the clients with a timeout of 13, but still get hints stored.

In our case, I would like for the cluster to wait for the write to be
persisted on the relevant nodes before returning an ok to the client. But I
don't know which knobs to turn to accomplish this? or if it is even
possible :)

We are running cassandra 3.0.3, with 8Gb heap and a replication factor of 3.

Thank you in advance!

Yours sincerely,
  Bo Madsen

Re: Cassandra causing OOM Killer to strike on new cluster running 3.4

[Paulo Motta]

2.2.6 should be released in the next couple of weeks, but I also attached a
patch file to the issue if you want to patch 2.2.5 manually.

2016-04-20 0:19 GMT-03:00 Satoshi Hikida :

> Hi,
>
> I'm looking forward to a  patch (file) for this bug(CASSANDRA-11344) to
> apply C* version 2.2.5. Is there available patch for that version? I
> watched link(https://issues.apache.org/jira/browse/CASSANDRA-11344) but
> couldn't find patch file or something like that.  Or is there any
> workaround to avoid this bug with version 2.2.5?
>
> Regards,
> Satoshi
>
> On Tue, Mar 15, 2016 at 4:47 AM, Adam Plumb  wrote:
>
>> OK so good news, I'm running with the patched jar file in my cluster and
>> haven't seen any issues.  The bloom filter off-heap memory usage is between
>> 1.5GB and 2GB per node, which is much more in-line with what I'm expecting!
>>  (thumbsup)
>>
>> On Mon, Mar 14, 2016 at 9:42 AM, Adam Plumb  wrote:
>>
>>> Thanks for the link!  Luckily the cluster I'm running is not yet in
>>> production and running with dummy data so I will throw that jar on the
>>> nodes and I'll let you know how things shake out.
>>>
>>> On Sun, Mar 13, 2016 at 11:02 PM, Paulo Motta 
>>> wrote:
>>>
 You could be hitting CASSANDRA-11344 (
 https://issues.apache.org/jira/browse/CASSANDRA-11344).  If that's the
 case, you may try to replace your cassandra jar on an affected node with a
 version with this fix in place and force bloom filter regeneration to see
 if if it fixes your problem. You can build with "ant jar" from this branch:
 https://github.com/pauloricardomg/cassandra/tree/3.4-11344

 You can force bloom filter regeneration by either removing your
 *Filter.db files (make sure to backup them before for safety) or changing
 the bloom_filter_fp_chance before restarting affected nodes with the fixed
 jar.

 2016-03-13 19:51 GMT-03:00 Adam Plumb :

> So it's looking like the bloom filter off heap memory usage is ramping
> up and up until the OOM killer kills the java process.  I relaunched on
> instances with 60GB of memory and the same thing is happening.  A node 
> will
> start using more and more RAM until the process is killed, then another
> node will start using more and more until it is also killed.
>
> Is this the expected behavior?  It doesn't seem ideal to me.  Is there
> anything obvious that I'm doing wrong?
>
> On Fri, Mar 11, 2016 at 11:31 AM, Adam Plumb  wrote:
>
>> Here is the creation syntax for the entire schema.  The xyz table has
>> about 2.1 billion keys and the def table has about 230 million keys.  Max
>> row size is about 3KB, mean row size is 700B.
>>
>> CREATE KEYSPACE abc WITH replication = {'class':
>>> 'NetworkTopologyStrategy', 'us-east': 3};
>>> CREATE TABLE xyz (
>>>   id text,
>>>   secondary_id int,
>>>   data text,
>>>   PRIMARY KEY(id)
>>> )
>>>   WITH
>>>   compaction = { 'class': 'LeveledCompactionStrategy' }
>>>   and compression = {'class': 'LZ4Compressor'};
>>> CREATE INDEX secondary_id_index ON abc.xyz (secondary_id);
>>> CREATE TABLE def (
>>>   id text,
>>>   secondary_id int,
>>>   data text,
>>>   PRIMARY KEY(id)
>>> )
>>>   WITH
>>>   compaction = { 'class': 'LeveledCompactionStrategy' }
>>>   and compression = {'class': 'LZ4Compressor'};
>>> CREATE INDEX secondary_id_index_def ON abc.def (secondary_id);
>>
>>
>> On Fri, Mar 11, 2016 at 11:24 AM, Jack Krupansky <
>> jack.krupan...@gmail.com> wrote:
>>
>>> What is your schema and data like - in particular, how wide are your
>>> partitions (number of rows and typical row size)?
>>>
>>> Maybe you just need (a lot) more heap for rows during the repair
>>> process.
>>>
>>> -- Jack Krupansky
>>>
>>> On Fri, Mar 11, 2016 at 11:19 AM, Adam Plumb 
>>> wrote:
>>>
 These are brand new boxes only running Cassandra.  Yeah the kernel
 is what is killing the JVM, and this does appear to be a memory leak in
 Cassandra.  And Cassandra is the only thing running, aside from the 
 basic
 services needed for Amazon Linux to run.

 On Fri, Mar 11, 2016 at 11:17 AM, Sebastian Estevez <
 sebastian.este...@datastax.com> wrote:

> Sacrifice child in dmesg is your OS killing the process with the
> most ram. That means you're actually running out of memory at the 
> Linux
> level outside of the JVM.
>
> Are you running anything other than Cassandra on this box?
>
> If so, does it have a memory leak?
>
> all the best,
>
> Sebastián
> On Mar 11, 2016 11:14 AM, "Adam Plumb" 

Re: Optional TLS CQL Encryption

[Jason Williams]

Hi Sam,

That's exactly what I was hoping for, but couldn't find in the docs. Thank you 
very much!

-J

Sent via iPhone

> On Apr 20, 2016, at 02:05, Sam Tunnicliffe  wrote:
> 
> From 3.0, separate ports can be configured for encrypted & non-encrypted 
> connections. 
> See https://issues.apache.org/jira/browse/CASSANDRA-9590
> 
>> On Wed, Apr 20, 2016 at 8:51 AM, Jason J. W. Williams 
>>  wrote:
>> Hi Ben,
>> 
>> Thanks for confirming what I saw occur. The Datastax drivers don't play very 
>> nicely with Twisted Python so connection pooling is inconsistent and makes 
>> always-on TLS a no-go performance-wise. The encryption overhead isn't the 
>> problem, it's the build-up of the TLS session for every connection when 
>> connection pooling is not working as needed. That said it is still 
>> beneficial to be able to enforce TLS for remote access...MySQL allows you to 
>> enforce TLS on a per-user basis for example. 
>> 
>> If someone has been successful not wrapping the Datastax drivers in 
>> deferToThread calls when using Twisted I'd appreciate insight on how you got 
>> that working because its pretty much undocumented.
>> 
>> -J
>> 
>>> On Tue, Apr 19, 2016 at 11:46 PM, Ben Bromhead  wrote:
>>> Hi Jason
>>> 
>>> If you enable encryption it will be always on. Optional encryption is 
>>> generally a bad idea (tm). Also always creating a new session every query 
>>> is also a bad idea (tm) even without the minimal overhead of encryption. 
>>> 
>>> If you are really hell bent on doing this you could have a node that is 
>>> part of the cluster but has -Dcassandra.join_ring=false set in jvm options 
>>> in cassandra-env.sh so it does not get any data and configure that to have 
>>> no encryption enabled. This is known as a fat client. Then connect to that 
>>> specific node whenever you want to do terrible non encrypted things.
>>> 
>>> Having said all that, please don't do this.
>>> 
>>> Cheers
>>> 
 On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams 
  wrote:
 Hey Guys,
 
 Is there a way to make TLS encryption optional for the CQL listener? We'd 
 like to be able to use for remote management connections but not for same 
 datacenter usage (since the build/up  tear down cost is too high for 
 things that don't use pools). 
 
 Right now it appears if we enable encryption it requires it for all 
 connections, which definitely is not what we want.
 
 -J
>>> 
>>> -- 
>>> Ben Bromhead
>>> CTO | Instaclustr
>>> +1 650 284 9692
>>> Managed Cassandra / Spark on AWS, Azure and Softlayer
> 

Re: Optional TLS CQL Encryption

[Sam Tunnicliffe]

>From 3.0, separate ports can be configured for encrypted & non-encrypted
connections.
See https://issues.apache.org/jira/browse/CASSANDRA-9590

On Wed, Apr 20, 2016 at 8:51 AM, Jason J. W. Williams <
jasonjwwilli...@gmail.com> wrote:

> Hi Ben,
>
> Thanks for confirming what I saw occur. The Datastax drivers don't play
> very nicely with Twisted Python so connection pooling is inconsistent and
> makes always-on TLS a no-go performance-wise. The encryption overhead isn't
> the problem, it's the build-up of the TLS session for every connection when
> connection pooling is not working as needed. That said it is still
> beneficial to be able to enforce TLS for remote access...MySQL allows you
> to enforce TLS on a per-user basis for example.
>
> If someone has been successful not wrapping the Datastax drivers in
> deferToThread calls when using Twisted I'd appreciate insight on how you
> got that working because its pretty much undocumented.
>
> -J
>
> On Tue, Apr 19, 2016 at 11:46 PM, Ben Bromhead 
> wrote:
>
>> Hi Jason
>>
>> If you enable encryption it will be always on. Optional encryption is
>> generally a bad idea (tm). Also always creating a new session every query
>> is also a bad idea (tm) even without the minimal overhead of encryption.
>>
>> If you are really hell bent on doing this you could have a node that is
>> part of the cluster but has -Dcassandra.join_ring=false set in jvm
>> options in cassandra-env.sh so it does not get any data and configure
>> that to have no encryption enabled. This is known as a fat client. Then
>> connect to that specific node whenever you want to do terrible non
>> encrypted things.
>>
>> Having said all that, please don't do this.
>>
>> Cheers
>>
>> On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams <
>> jasonjwwilli...@gmail.com> wrote:
>>
>>> Hey Guys,
>>>
>>> Is there a way to make TLS encryption optional for the CQL listener?
>>> We'd like to be able to use for remote management connections but not for
>>> same datacenter usage (since the build/up  tear down cost is too high for
>>> things that don't use pools).
>>>
>>> Right now it appears if we enable encryption it requires it for all
>>> connections, which definitely is not what we want.
>>>
>>> -J
>>>
>> --
>> Ben Bromhead
>> CTO | Instaclustr 
>> +1 650 284 9692
>> Managed Cassandra / Spark on AWS, Azure and Softlayer
>>
>
>

Re: Optional TLS CQL Encryption

[Jason J. W. Williams]

Hi Ben,

Thanks for confirming what I saw occur. The Datastax drivers don't play
very nicely with Twisted Python so connection pooling is inconsistent and
makes always-on TLS a no-go performance-wise. The encryption overhead isn't
the problem, it's the build-up of the TLS session for every connection when
connection pooling is not working as needed. That said it is still
beneficial to be able to enforce TLS for remote access...MySQL allows you
to enforce TLS on a per-user basis for example.

If someone has been successful not wrapping the Datastax drivers in
deferToThread calls when using Twisted I'd appreciate insight on how you
got that working because its pretty much undocumented.

-J

On Tue, Apr 19, 2016 at 11:46 PM, Ben Bromhead  wrote:

> Hi Jason
>
> If you enable encryption it will be always on. Optional encryption is
> generally a bad idea (tm). Also always creating a new session every query
> is also a bad idea (tm) even without the minimal overhead of encryption.
>
> If you are really hell bent on doing this you could have a node that is
> part of the cluster but has -Dcassandra.join_ring=false set in jvm
> options in cassandra-env.sh so it does not get any data and configure
> that to have no encryption enabled. This is known as a fat client. Then
> connect to that specific node whenever you want to do terrible non
> encrypted things.
>
> Having said all that, please don't do this.
>
> Cheers
>
> On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams <
> jasonjwwilli...@gmail.com> wrote:
>
>> Hey Guys,
>>
>> Is there a way to make TLS encryption optional for the CQL listener? We'd
>> like to be able to use for remote management connections but not for same
>> datacenter usage (since the build/up  tear down cost is too high for things
>> that don't use pools).
>>
>> Right now it appears if we enable encryption it requires it for all
>> connections, which definitely is not what we want.
>>
>> -J
>>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>

Re: Optional TLS CQL Encryption

[Ben Bromhead]

Hi Jason

If you enable encryption it will be always on. Optional encryption is
generally a bad idea (tm). Also always creating a new session every query
is also a bad idea (tm) even without the minimal overhead of encryption.

If you are really hell bent on doing this you could have a node that is
part of the cluster but has -Dcassandra.join_ring=false set in jvm options
in cassandra-env.sh so it does not get any data and configure that to have
no encryption enabled. This is known as a fat client. Then connect to that
specific node whenever you want to do terrible non encrypted things.

Having said all that, please don't do this.

Cheers

On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams 
wrote:

> Hey Guys,
>
> Is there a way to make TLS encryption optional for the CQL listener? We'd
> like to be able to use for remote management connections but not for same
> datacenter usage (since the build/up  tear down cost is too high for things
> that don't use pools).
>
> Right now it appears if we enable encryption it requires it for all
> connections, which definitely is not what we want.
>
> -J
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer