Re: [DISCUSS] Donating easy-cass-stress to the project

Hi folks, I'm familiar with the codebase and can help with the maintenance and evolution. I already have some additional profiles that I can push there which were never merged in the main branch of tlp-cluster. I love this tool (I know I'm biased) and hope it gets the attention it deserves. Le

Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers

Congratulations folks! And thanks for all the hard work throughout the years on the Java Driver! Le jeu. 18 avr. 2024 à 08:39, Jean-Armel Luce a écrit : > Congratulations everyone !!! > > Le jeu. 18 avr. 2024 à 07:37, Berenguer Blasi > a écrit : > >> Congrats all! >> On 17/4/24 23:23, Jeremiah

Re: [DISCUSSION] CEP-38: CQL Management API

Hi Maxim, I'm part of the K8ssandra team and am very happy to hear that you like our management API design. Looking at the CEP, I see that your current target design mentions the k8ssandra-management-api. What do you have in mind specifically there? Do you plan on rewriting a brand new

Re: [DISCUSS] Revisiting the quality testing epic scope

I confirm we're almost done with CASSANDRA-15580 (Repair QA testing). Nightly runs are scheduled already and I'm tuning some knobs to get them nicely stable: https://app.circleci.com/pipelines/github/riptano/cassandra-rtest?branch=trunk Andres also created an in-jvm dtest for the mixed cluster

Re: [Discuss] num_tokens default in Cassandra 4.0

compromise for clusters of all sizes, without being too aggressive. Those with enough C* experience can still lower that number for their clusters. Cheers, - Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com On Fri

Re: Update defaults for 4.0?

rule for computing the new gen size doesn't make any sense IMO (at least in the context of Cassandra). This is one of the most common optimizations we make on clusters, and most peeps that run Cassandra aren't GC experts (and shouldn't be). - Alexander Dejanovski France

Re: Deprecating/removing PropertyFileSnitch?

;>>>>>>>> > >>>>>>>>>>>>>>> On Tue, Oct 16, 2018 at 10:04 AM Jeremiah D Jordan < > >>>>>>>>>>>>>>> jeremiah.jor...@gmail.com> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> As long as we are correctly storing such things in the > >> system > >>>>>>>>>>> tables > >>>>>>>>>>>>> and > >>>>>>>>>>>>>>>> reading them out of the system tables when we do not have > >> the > >>>>>>>>>>>>> information > >>>>>>>>>>>>>>>> from gossip yet, it should not be a problem. (As far as I > >> know > >>>>>>>>>> GPFS > >>>>>>>>>>>>> does > >>>>>>>>>>>>>>>> this, but I have not done extensive code diving or testing > >> to > >>>>>>>>>> make > >>>>>>>>>>>>> sure all > >>>>>>>>>>>>>>>> edge cases are covered there) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -Jeremiah > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Oct 16, 2018, at 11:56 AM, sankalp kohli < > >>>>>>>>>>> kohlisank...@gmail.com > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Will GossipingPropertyFileSnitch not be vulnerable to > >> Gossip > >>>>>>>>>> bugs > >>>>>>>>>>>>> where > >>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>> lose hostId or some other fields when we restart C* for > >> large > >>>>>>>>>>>>>>>>> clusters(~1000 instances)? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa < > >> jji...@gmail.com> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> We should, but the 4.0 features that log/reject verbs to > >>>>>>>>>> invalid > >>>>>>>>>>>>>>>> replicas > >>>>>>>>>>>>>>>>>> solves a lot of the concerns here > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>> Jeff Jirsa > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Oct 16, 2018, at 4:10 PM, Jeremy Hanna < > >>>>>>>>>>>>> jeremy.hanna1...@gmail.com> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> We have had PropertyFileSnitch for a long time even > >> though > >>>>>>>>>>>>>>>>>> GossipingPropertyFileSnitch is effectively a superset of > >> what > >>>>>>>>>> it > >>>>>>>>>>>>> offers > >>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> is much less error prone. There are some unexpected > >> behaviors > >>>>>>>>>>> when > >>>>>>>>>>>>>>>> things > >>>>>>>>>>>>>>>>>> aren’t configured correctly with PFS. For example, if > you > >>>>>>>>>>> replace > >>>>>>>>>>>>>>>> nodes in > >>>>>>>>>>>>>>>>>> one DC and add those nodes to that DCs property files > and > >> not > >>>>>>>>>> the > >>>>>>>>>>>>> other > >>>>>>>>>>>>>>>> DCs > >>>>>>>>>>>>>>>>>> property files - the resulting problems aren’t very > >>>>>>>>>>> straightforward > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> troubleshoot. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> We could try to improve the resilience and fail fast > >> error > >>>>>>>>>>>> checking > >>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> error reporting of PFS, but honestly, why wouldn’t we > >> deprecate > >>>>>>>>>>> and > >>>>>>>>>>>>>>>> remove > >>>>>>>>>>>>>>>>>> PropertyFileSnitch? Are there reasons why GPFS wouldn’t > >> be > >>>>>>>>>>>>> sufficient > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> replace it? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> > - > >>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >> dev-unsubscr...@cassandra.apache.org > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: > >>>>>>>>>> dev-h...@cassandra.apache.org > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> > >> - > >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >> dev-unsubscr...@cassandra.apache.org > >>>>>>>>>>>>>>>>>> For additional commands, e-mail: > >> dev-h...@cassandra.apache.org > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>> > >> - > >>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >> dev-unsubscr...@cassandra.apache.org > >>>>>>>>>>>>>>>> For additional commands, e-mail: > >> dev-h...@cassandra.apache.org > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> > >> - > >>>>>>>>>>>>>> To unsubscribe, e-mail: > dev-unsubscr...@cassandra.apache.org > >>>>>>>>>>>>>> For additional commands, e-mail: > >> dev-h...@cassandra.apache.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> > - > >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>>>>>>>>>>> For additional commands, e-mail: > dev-h...@cassandra.apache.org > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >> - > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> - > >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>>> > >>>> > >>>> - > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>> > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>> > >> > >> > > -- - Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com

Re: Debug logging enabled by default since 2.2

wer because right now we are in the > process of eliminating the distinction we used to make which is that DEBUG > is safe to turn on in production and TRACE is not. > > Ariel > > On Tue, Mar 20, 2018, at 12:36 PM, Alexander Dejanovski wrote: > > Ariel, > > > >

Re: Debug logging enabled by default since 2.2

er < > https://logback.qos.ch/manual/layouts.html#marker> > > >>> https://www.slf4j.org/faq.html#fatal < > https://www.slf4j.org/faq.html#fatal> > > >>> > > >>> > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- - Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com

Re: Debug logging enabled by default since 2.2

; >>>>> we can spot a variety of performance issues introduced by all kinds > of > >>>>> changes. > >>>>> > >>>>> Ariel > >>>>> > >>>>>> On Mar 18, 2018, at 3:46 PM, Jeff Jirsa <jji

Re: Debug logging enabled by default since 2.2

st likely those should be moved to TRACE so that debug > logging can stay enabled for all the useful information found there. > >> > >> -Jeremiah > >> > >>> On Mar 17, 2018, at 1:49 PM, Alexander Dejanovski < > a...@thelastpickle.com> wrote: &g

Debug logging enabled by default since 2.2

and that it lowers read performance in 2.2. Was there any specific reason why it was enabled by default in 2.2 ? Is anyone opposed to disabling debug logging by default in all branches ? -- - Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http

Re: CASSANDRA-8527

> I’m > > a solid +1 on introducing it to help with testing. In an ideal world > we’d > > have no singletons and could test everything in isolation, but > > realistically that’s a multi year process and we just aren’t there. > > > > > > > On Dec 19, 2017, at 11:07

CASSANDRA-8527

write some tests without starting the whole stack. Thanks, -- - Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com

Re: repair hangs, validation failed

-- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- - Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com