Re: Deprecating/removing PropertyFileSnitch?

2018-10-19 Thread Sankalp Kohli
Say you restarted all instances in the cluster and status for some host goes missing. Now when you start a host replacement, the new host won’t learn about the host whose status is missing and the view of this host will be wrong. PS: I will be happy to be proved wrong as I can also start using

Re: Deprecating/removing PropertyFileSnitch?

2018-10-19 Thread Jeremy Hanna
Do you mean to say that during host replacement there may be a time when the old->new host isn’t fully propagated and therefore wouldn’t yet be in all system tables? > On Oct 17, 2018, at 4:20 PM, sankalp kohli wrote: > > This is not the case during host replacement correct? > > On Tue, Oct

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Jonathan Haddad
Sorry, to be clear - I'm +1 on changing the configuration default, but I think changing the compression in memory representations warrants further discussion and investigation before making a case for or against it yet. An optimization that reduces in memory cost by over 50% sounds pretty good and

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Jonathan Haddad
I think we should try to do the right thing for the most people that we can. The number of folks impacted by 64KB is huge. I've worked on a lot of clusters created by a lot of different teams, going from brand new to pretty damn knowledgeable. I can't think of a single time over the last 2

Re: Using Cassandra as local db without cluster

2018-10-19 Thread Abdelkrim Fitouri
Thanks for the infos, I will try aerospike also, they are always including a one node installation on there benchmarking and are also talking about vertical scalability. Kind regards. Le jeu. 18 oct. 2018 14:44, Aleksey Yeshchenko a écrit : > I agree with Jeff here. > > Furthermore,

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Sankalp Kohli
(We should definitely harden the definition for freeze in a separate thread) My thinking is that this is the best time to do this change as we have not even cut alpha or beta. All the people involved in the test will definitely be testing it again when we have these releases. > On Oct 19,

Re: Built in trigger: double-write for app migration

2018-10-19 Thread Carl Mueller
Also we have 2.1.x and 2.2 clusters, so we can't use CDC since apparently that is a 3.8 feature. Virtual tables are very exciting so we could do some collating stuff (which I'd LOVE to do with our scheduling application where we can split tasks into near term/most frequent(hours to days),

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Michael Shuler
On 10/19/18 9:16 AM, Joshua McKenzie wrote: > > At the risk of hijacking this thread, when are we going to transition from > "no new features, change whatever else you want including refactoring and > changing years-old defaults" to "ok, we think we have something that's > stable, time to start

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Benedict Elliott Smith
Shall we move this discussion to a separate thread? I agree it needs to be had, but this will definitely derail this discussion. To respond only to the relevant portion for this thread: > changing years-old defaults I don’t see how age is relevant? This isn’t some ‘battle hardened’ feature

Re: Built in trigger: double-write for app migration

2018-10-19 Thread Carl Mueller
new DC and then split is one way, but you have to wait for it to stream, and then how do you know the dc coherence is good enough to switch the targetted DC for local_quorum? And then once we split it we'd have downtime to "change the name" and other work that would distinguish it from the

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Joshua McKenzie
> > The predominant phrased used in that thread was 'feature freeze'. At the risk of hijacking this thread, when are we going to transition from "no new features, change whatever else you want including refactoring and changing years-old defaults" to "ok, we think we have something that's stable,

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Ariel Weisberg
Hi, I ran some benchmarks on my laptop https://issues.apache.org/jira/browse/CASSANDRA-13241?focusedCommentId=16656821=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16656821 For a random read workload, varying chunk size: Chunk size Time 64k 25:20

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Benedict Elliott Smith
The change of default property doesn’t seem to violate the freeze? The predominant phrased used in that thread was 'feature freeze'. A lot of people are now interpreting it more broadly, so perhaps we need to revisit, but that’s probably a separate discussion? The current default is really

Re: Proposing an Apache Cassandra Management process

2018-10-19 Thread Mick Semb Wever
> Can you share the link to cwiki if you have started it ? > I haven't. But I'll try to put together a strawman proposal for the doc(s) over the weekend. Regards, Mick - To unsubscribe, e-mail:

Re: Built in trigger: double-write for app migration

2018-10-19 Thread Antonis Papaioannou
It reminds me of “shadow writes” described in [1]. During data migration the coordinator forwards a copy of any write request regarding tokens that are being transferred to the new node. [1] Incremental Elasticity for NoSQL Data Stores, SRDS’17, https://ieeexplore.ieee.org/document/8069080

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Jeff Jirsa
Agree with Sylvain (and I think Benedict) - there’s no compelling reason to violate the freeze here. We’ve had the wrong default for years - add a note to the docs that we’ll be changing it in the future, but let’s not violate the freeze now. -- Jeff Jirsa > On Oct 19, 2018, at 10:06 AM,

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Sylvain Lebresne
Fwiw, as much as I agree this is a change worth doing in general, I do am -0 for 4.0. Both the "compact sequencing" and the change of default really. We're closing on 2 months within the freeze, and for me a freeze do include not changing defaults, because changing default ideally imply a decent