Re: [VOTE] Release dtest-api 0.0.16

+1On Aug 17, 2023, at 12:37 AM, Alex Petrov wrote:+1On Thu, Aug 17, 2023, at 4:46 AM, Brandon Williams wrote:+1Kind Regards,BrandonOn Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi wrote:>> Proposing the test build of in-jvm dtest API 0.0.16 for release.>> Repository:> 

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

+1 > On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa wrote: > > Hi Everyone! > > I would like to start a vote thread for CEP-34. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators > JIRA

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 > On Feb 6, 2023, at 8:15 AM, Sam Tunnicliffe wrote: > > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > Discussion: >

Re: [DISCUSS] Removing support for java 8

efficient so that people on all > ends can progress with whatever they work on. Let’s talk to Mick and put down > the pin-points and assess the plan? How about that? > > On Mon, 29 Aug 2022 at 17:25, Blake Eggleston <mailto:beggles...@apple.com>> wrote: > Can you say som

Re: [DISCUSS] Removing support for java 8

to avoid making extra work. > > Kind Regards, > Brandon > > On Mon, Aug 29, 2022 at 3:40 PM Blake Eggleston wrote: >> >> Sorry, I meant trunk, not 4.1 :) >> >>> On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: >>> >>> Hi all, I wante

Re: [DISCUSS] Removing support for java 8

Yes I'd seen the 11+17 thread, but didn't see anything about an explicit jdk8 removal (ie: removal from CI etc). Ekaterina informed me there was an earlier thread covering that though > On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: > > Hi all, I wanted to propose removing jdk

Re: [DISCUSS] Removing support for java 8

Sorry, I meant trunk, not 4.1 :) > On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: > > Hi all, I wanted to propose removing jdk8 support for 4.1. Active support > ended back in March of this year, and I believe the community has built > enough confidence in

[DISCUSS] Removing support for java 8

Hi all, I wanted to propose removing jdk8 support for 4.1. Active support ended back in March of this year, and I believe the community has built enough confidence in java 11 to make it an uncontroversial change for our next major release. Let me know what you think. Thanks, Blake

Re: CEP-15 multi key transaction syntax

I think we’ve converged on a starting syntax. Are there any additional comments before I open a JIRA? > On Jun 16, 2022, at 10:33 AM, Blake Eggleston wrote: > > I think in any scenario where the same cell is updated multiple times, the > last one would win. The final result fo

Re: CEP-15 multi key transaction syntax

at itself yields NULL) > > This is explicitly stipulated in ANSI SQL 92, in 6.12 expression>: > > General Rules > > 1) If the value of any simply contained in a > is the null value, then the result of > the is the null value. >

Re: CEP-15 multi key transaction syntax

Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a little trickier. Assigning null to a column seems ok, but we should raise an exception if they're doing math or something that expects a non-null value > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith > wrote:

Re: CEP-15 multi key transaction syntax

I see what you mean. We have the EXISTS/NOT EXISTS condition for explicitly checking for the existence of a row. One thing the old syntax did is how it handled references to columns that don't exist. Previously, if any column reference didn't resolve, the update wouldn't apply. With the new

Re: CEP-15 multi key transaction syntax

, this would simplify the initial implementation, and let feature requests and first hand experience inform where and how the syntax develops from there. Blake > On Jun 13, 2022, at 12:14 PM, Blake Eggleston wrote: > > Does the IF <...> ABORT simplify reasoning though? If you rest

Re: CEP-15 multi key transaction syntax

people > on what they think. > > > Patrick > > > On Fri, Jun 10, 2022 at 12:07 PM bened...@apache.org > <mailto:bened...@apache.org> <mailto:bened...@apache.org>> wrote: > > This might also permit us to remove one result set (the success/fai

Re: CEP-15 multi key transaction syntax

t; IF q1.a != 1 ROLLBACK TRANSACTION > UPDATE tbl SET a = q1.a + 1 WHERE k = 1 AS q2 > COMMIT TRANSACTION > > This is less succinct, but might be more familiar to users. We could also > eschew the ability to read from UPDATE statements entirely in this scheme, as > this would the

Re: CEP-15 multi key transaction syntax

to single rows we are updating, so we could simply maintain a > collections of rows and upsert into them as we process the execution. Most > transactions won’t need it, I suspect, so we don’t need to worry about > perfect efficiency. > > > From: Blake Eggleston > Date: Tuesday, 7 J

Re: CEP-15 multi key transaction syntax

think highly desirable for user experience, but this > does complicate it a bit if we want to remain intuitive. > > > > > From: Blake Eggleston > Date: Monday, 6 June 2022 at 23:17 > To: dev@cassandra.apache.org > Subject: Re: CEP-15 multi key transaction syntax > &

Re: CEP-15 multi key transaction syntax

Hi all, Thanks for all the input and questions so far. Glad people are excited about this! I didn’t have any free time to respond this weekend, although it looks like Benedict has responded to most of the questions so far, so if I don’t respond to a question you asked here, you can interpret

CEP-15 multi key transaction syntax

Hi dev@, I’ve been working on a draft syntax for Accord transactions and wanted to bring what I have to the dev list to solicit feedback and build consensus before moving forward with it. The proposed transaction syntax is intended to be an extended batch syntax. Basically batches with

Re: [DISCUSS] Mentoring newcomers

I’m happy to help out > On Nov 12, 2021, at 9:04 AM, Benjamin Lerer wrote: > > Hi everybody > > As discussed in the *Creating a new slack channel for newcomers* thead, a > solution to help newcomers engage with the project would be to provide a > list of mentors that newcomers can contact when

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 2. +1 3. +1 > On Oct 14, 2021, at 9:31 AM, bened...@apache.org wrote: > > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, as > discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the

Re: Tradeoffs for Cassandra transaction management

f the way while a vote on CEP-15 seemed > imminent. But discussing this tradeoffs thread with Jonathan, he encouraged > me to say these points in my own words, so here we are. > > > On Sun, Oct 10, 2021 at 7:17 AM Blake Eggleston > mailto:beggles...@apple.com.invalid>> wrot

Re: Tradeoffs for Cassandra transaction management

Let’s get back on topic. Jonathan, in your opening email you stated that, in your view, the 2 main areas of tradeoff were: > 1. Is it worth giving up local latencies to get full global consistency? Now we’ve established that we don’t need to give up local latencies with Accord, which leaves:

Re: Tradeoffs for Cassandra transaction management

avoid it also, but if we’re going to compare Accord against a hypothetical SQL feature that seems to lack design goals, or any clear ideas about how it might be implemented, I don’t think we can rule it out. > On Oct 11, 2021, at 6:02 AM, Jonathan Ellis wrote: > > On Sat, Oct 9, 2021 a

Re: Tradeoffs for Cassandra transaction management

1. Is it worth giving up local latencies to get full global consistency? Most LWT use cases use LOCAL_SERIAL. This isn’t a tradeoff that needs to be made. There’s nothing about Accord that prevents performing consensus in one DC and replicating the writes to others. That’s not in scope for the

Re: [DISCUSS] CEP-15: General Purpose Transactions

You could establish a lower timestamp bound and buffer transaction state on the coordinator, then make the commit an operation that only applies if all partitions involved haven’t been changed by a more recent timestamp. You could also implement mvcc either in the storage layer or for some

Re: [DISCUSS] CEP-15: General Purpose Transactions

Hi Jake, > 1. Will this effort eventually replace consistency levels in C*? I ask > because one of the shortcomings of our paxos today is > it can be easily mixed with non serialized consistencies and therefore > users commonly break consistency by for example reading at CL.ONE while > also >

Re: [VOTE] Release Apache Cassandra 4.0.1

+1 > On Sep 1, 2021, at 4:54 AM, Sam Tunnicliffe wrote: > > Proposing the test build of Cassandra 4.0.1 for release. > > sha1: 6709111ed007a54b3e42884853f89cabd38e4316 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative > Maven Artifacts: >

Re: [VOTE] CEP-14: Paxos Improvements

+1 > On Aug 27, 2021, at 12:48 PM, bened...@apache.org wrote: > > Hi everyone, I’m proposing this CEP for approval. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements > Discussion: >

Re: [DISCUSS] Repair Improvement Proposal

+1 from me, any improvement in this area would be great. It would be nice if this could include visibility into repair streams, but just exposing the repair state will be a big improvement. > On Aug 25, 2021, at 5:46 PM, David Capwell wrote: > > Now that 4.0 is out, I want to bring up

Re: [VOTE] CEP-10: Cluster and Code Simulations

+1 > On Jul 27, 2021, at 9:21 PM, Scott Andreas wrote: > > +1 nb > > > From: Sam Tunnicliffe > Sent: Tuesday, July 27, 2021 12:54 AM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] CEP-10: Cluster and Code Simulations > > +1 > >> On 26 Jul

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

+1 > On Jul 23, 2021, at 6:39 AM, Branimir Lambov > wrote: > > +1 > >> On Fri, Jul 23, 2021 at 4:15 PM Aleksey Yeschenko >> wrote: >> >> +1 >> On 23 Jul 2021, at 14:03, Joshua McKenzie wrote: >>> >>> +1 >>> >>> On Fri, Jul 23, 2021 at 8:07 AM Dinesh Joshi >> >>> wrote: >>>

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 > On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko wrote: > > +1 > >> On 14 Jul 2021, at 15:37, Jonathan Ellis wrote: >> >> +1 >> >>> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever wrote: >>> >>> Proposing the test build of Cassandra 4.0.0 for release. >>> >>> sha1:

Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

+1 > On Apr 21, 2021, at 2:25 PM, Scott Andreas wrote: > > +1nb, thank you! > > > From: Ekaterina Dimitrova > Sent: Wednesday, April 21, 2021 12:23 PM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2) > >

Re: [VOTE] Release Apache Cassandra 4.0-rc1

+1 > On Mar 29, 2021, at 6:05 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0-rc1 for release. > > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative > Maven Artifacts: >

Re: [VOTE] Release dtest-api 0.0.7

+1, sorry for the html barf :) > On Dec 3, 2020, at 9:53 AM, Blake Eggleston > wrote: > > Proposing the test build of in-jvm dtest API 0.0.7 for > release. > > Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags

Re: [VOTE] Release dtest-api 0.0.7

Proposing the test build of in-jvm dtest API 0.0.7 for release. Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.7 Candidate SHA:https://github.com/apache/cassandra-in-jvm-dtest-api/commit/d5174b1f44b7d9cb919d4975b4d437041273c09c tagged

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

amed for choosing correctness is easier to live with ;-) >> >> Benjamin >> >> PS: I tried to push the choice on Sylvain but he dodged the bullet. >> >> On Sat, Nov 21, 2020 at 12:30 AM Benedict Elliott Smith < >> bened...@apache.org> >> wrote: >>

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

I’d also prefer #3 over #4 > On Nov 20, 2020, at 10:03 AM, Benedict Elliott Smith > wrote: > > Well, I expressed a preference for #3 over #4, particularly for the 3.x > series. However at this point, I think the lack of a clear project decision > means we can punt it back to you and

Re: [VOTE] Accept the Harry donation

+1 > On Sep 16, 2020, at 2:45 AM, Mick Semb Wever wrote: > > This vote is about officially accepting the Harry donation from Alex Petrov > and Benedict Elliott Smith, that was worked on in CASSANDRA-15348. > > The Incubator IP Clearance has been filled out at >

Re: [DISCUSS] Change style guide to recommend use of @Override

+1 > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > Currently our style guide recommends to avoid using @Override and updates > intellij's code style to exclude it by default; I would like to propose we > change this recommendation to use it and to update intellij's style to > include it

Re: [VOTE] Release Apache Cassandra 4.0-beta2

+1 > On Aug 28, 2020, at 7:18 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0-beta2 for release. > > sha1: 56eadf2004399a80f0733041cacf03839832249a > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta2-tentative > Maven

Re: [VOTE] Release Apache Cassandra 3.0.22

+1 > On Aug 28, 2020, at 6:09 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.0.22 for release. > > sha1: 45331bb612dc7847efece7e26cdd0b376bd11249 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.22-tentative > Maven Artifacts: >

Re: [VOTE] Release Apache Cassandra 2.1.22

+1 > On Aug 28, 2020, at 8:55 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Aug 28, 2020 at 8:42 AM Mick Semb Wever wrote: > >> Proposing the test build of Cassandra 2.1.22 for release. >> >> sha1: 94e9149c22f6a7772c0015e1b1ef2e2961155c0a >> Git: >> >>

Re: [VOTE] Release Apache Cassandra 2.2.18

+1 > On Aug 28, 2020, at 5:44 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 2.2.18 for release. > > sha1: d4938cf4e488a9ef3ac48164a3e946f16255d721 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.18-tentative > Maven Artifacts: >

Re: [VOTE] Release Apache Cassandra 3.11.8

+1 > On Aug 28, 2020, at 6:37 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.11.8 for release. > > sha1: 8b29b698630960a0ebb2c695cc5b21dee4686d09 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.8-tentative > Maven Artifacts: >

Re: Check in on CASSANDRA-15393

The later, the more risk to stability of > GA due to lack of time soaking. > > On Thu, Aug 27, 2020 at 4:01 PM Blake Eggleston > wrote: > >> Hi dev@, >> >> Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's >> some concern regard

Check in on CASSANDRA-15393

Hi dev@, Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's some concern regarding the patch and it's suitability for inclusion in 4.0-beta. CASSANDRA-15393 reduces garbage created by compaction and the read paths by about 25%. It's part of CASSANDRA-15387, which,

Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)

+1 > On Jul 20, 2020, at 9:56 AM, Jon Haddad wrote: > > +1, thanks Mick for rerolling. > > On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie > wrote: > >> +1 >> >> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote: >> >>> +1 >>> >>> On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña < >>>

Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)

Characterizing alternate or conflicting points of view as assuming bad intentions without justification is both unproductive and unhealthy for the project. > On Jul 20, 2020, at 9:14 AM, Joshua McKenzie wrote: > > This kind of back and forth isn't productive for the project so I'm not >

Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)

I don't think Benedict mentioned anything about people's motives or intentions, he simply had a concern about how marketing timelines became a factor in a release vote without the approval of the PMC. I think this is a reasonable concern, and doesn't mean that he's assuming bad intentions.

Re: [DISCUSS] Future of MVs

+1 for deprecation and removal (assuming a credible plan to fix them doesn't materialize) > On Jun 30, 2020, at 12:43 PM, Jon Haddad wrote: > > A couple days ago when writing a separate email I came across this DataStax > blog post discussing MVs [1]. Imagine my surprise when I noticed the

Re: [VOTE] Project governance wiki doc (take 2)

+1 > On Jun 20, 2020, at 8:12 AM, Joshua McKenzie wrote: > > Link to doc: > https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance > > Change since previous cancelled vote: > "A simple majority of this electorate becomes the low-watermark for votes > in

Re: [VOTE] Release Apache Cassandra 4.0-alpha4

+1 > On Apr 14, 2020, at 5:09 AM, e.dimitr...@gmail.com wrote: > > I also can’t see them. I think it matters to which interface is the link. > > And +1 from me, thanks! > >> On 14 Apr 2020, at 7:53, Erick Ramirez wrote: >> >>  >>> >>> All java8 UTs, jvmdtests and dtests pass

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

+1 > On Oct 25, 2019, at 8:57 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 8:06 AM Jon Haddad wrote: > >> +1 >> >> On Fri, Oct 25, 2019 at 10:18 AM Sam Tunnicliffe wrote: >> >>> +1 >>> On 24 Oct 2019, at 18:26, Michael Shuler >> wrote: I propose the

Re: [VOTE] Release Apache Cassandra 3.11.5

+1 > On Oct 25, 2019, at 8:58 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 24 Oct 2019, at 18:26, Michael Shuler wrote: >>> >>> I propose the following artifacts for release as 3.11.5. >>> >>> sha1:

Re: [VOTE] Release Apache Cassandra 2.2.15

+1 > On Oct 25, 2019, at 8:57 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 24 Oct 2019, at 18:25, Michael Shuler wrote: >>> >>> I propose the following artifacts for release as 2.2.15. >>> >>> sha1:

Re: [VOTE] Release Apache Cassandra 3.0.19

+1 > On Oct 25, 2019, at 8:58 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 24 Oct 2019, at 18:25, Michael Shuler wrote: >>> >>> I propose the following artifacts for release as 3.0.19. >>> >>> sha1:

Re: Can we kick off a release?

Looks like 15193 has been committed. Are we waiting on anything else before cutting the next set of releases? > On Oct 8, 2019, at 1:11 PM, Jon Haddad wrote: > > I forgot to mention, we should also release alpha2 of 4.0. > > > On Tue, Oct 8, 2019 at 1:04 PM Michael Shuler > wrote: > >>

Re: fixing paging state for 4.0

Sorry, I misread your earlier email. Yes, there are drivers that do mixed protocol versions. Not sure if the 4.0 java driver does, but at least one previous version did. > On Sep 24, 2019, at 7:19 PM, Blake Eggleston > wrote: > > Yes, but if a client is connected to 2 dif

Re: fixing paging state for 4.0

upport it. Or they will connect to the newer nodes with the older >>> protocol version. In either of those cases there is no problem. >>> >>> Protocol changes aside, I would suggest fixing the bug starting back on >>> 3.x by changing the meaning of

Re: fixing paging state for 4.0

ta. > Which realistically is probably what someone who sets the protocol level > query limit to Integer.MAX_VALUE is trying to do. > > -Jeremiah > >> On Sep 24, 2019, at 4:09 PM, Blake Eggleston >> wrote: >> >> Right, mixed version clusters. The opaqu

Re: fixing paging state for 4.0

re > something else that makes it a problem? > > On Tue, Sep 24, 2019 at 11:03 AM Blake Eggleston > wrote: > >> Changing paging state format is kind of a pain since the driver treats it >> as an opaque blob. I'd prefer we went with Sylvain's suggestion to just >> in

Re: Attention to serious bug CASSANDRA-15081

This looks like a dupe of CASSANDRA-15086, which has been committed and will be included in 3.0.19. > On Sep 11, 2019, at 5:10 PM, Cameron Zemek wrote: > > Have had multiple customer hit this CASSANDRA-15081 issue now, where > upgrading from older versions the sstables contain an unknown

Re: fixing paging state for 4.0

Changing paging state format is kind of a pain since the driver treats it as an opaque blob. I'd prefer we went with Sylvain's suggestion to just interpret Integer.MAX_VALUE as "no limit", which would be a lot simpler to implement. > On Sep 24, 2019, at 10:44 AM, Jon Haddad wrote: > > I'm

Time for a new 3.0/3.11 release?

Hi dev@, Any objections to doing a new 3.0 and 3.11 release? Both branches have accumulated a decent number of changes since their last release, the highlights being improved merkle tree footprint, a gossip race, and a handful of 2.1 -> 3.x upgrade bugs. Thanks, Blake

Re: Stabilising Internode Messaging in 4.0

It seems like one of the main points of contention isn’t so much the the content of the patch, but more about the amount of review this patch has/will receive relative to its perceived risk. If it’s the latter, then I think it would be more effective to explain why that’s the case, and what

Re: Stabilising Internode Messaging in 4.0

Well said Josh. You’ve pretty much summarized my thoughts on this as well. +1 to moving forward with this > On Apr 11, 2019, at 10:15 PM, Joshua McKenzie wrote: > > As one of the two people that re-wrote all our unit tests to try and help > Sylvain get 8099 out the door, I think it's

Re: Both Java 8 and Java 11 required for producing a tarball

You may want to wait until CASSANDRA-14607 is finished before starting on 14712. I think it will end up unwinding most of the stuff requiring building with dual jdks (either as part of that ticket or an immediate follow on). I'm still working on making sure I haven't broken anything, but I'm

Re: Modeling Time Series data

This is a question for the user list. > On Jan 11, 2019, at 1:51 PM, Akash Gangil wrote: > > Hi, > > I have a data model where the partition key for a lot of tables is based on > time > (year, month, day, hour) > > Would this create a hotspot in my cluster, given all the writes/reads would >

Re: [VOTE] Change Jira Workflow

+1 > On Dec 17, 2018, at 9:31 AM, jay.zhu...@yahoo.com.INVALID wrote: > > +1 > >On Monday, December 17, 2018, 9:10:55 AM PST, Jason Brown > wrote: > > +1. > > On Mon, Dec 17, 2018 at 7:36 AM Michael Shuler > wrote: > >> +1 >> >> -- >> Michael >> >> On 12/17/18 9:19 AM, Benedict

Re: JIRA Workflow Proposals

1: A 2: +1 3: +1 4: +1 5: +1 6: +1 > On Dec 4, 2018, at 11:19 AM, Benedict Elliott Smith > wrote: > > Sorry, 4. Is inconsistent. First instance should be. > >> - 4. Priorities: Keep ‘High' priority > > >> On 4 Dec 2018, at 19:12, Benedict Elliott Smith > >

Re: Proposing an Apache Cassandra Management process

Reading through the history Sankalp posted (I think it was originally posted by Joey?), I think part of the problem we’re having here is that we’re trying to solve at least 3 problems with a single solution. Also, I don’t think everyone has the same goals in mind. The issues we’re trying to

Re: Proposing an Apache Cassandra Management process

t 6:53 PM, Blake Eggleston wrote: > > What’s the benefit of doing it that way vs starting with reaper and > integrating the netflix scheduler? If reaper was just a really inappropriate > choice for the cassandra management process, I could see that being a better > approach,

Re: Proposing an Apache Cassandra Management process

and isolated and layering on top. -- Jeff Jirsa > On Sep 7, 2018, at 5:42 PM, Blake Eggleston wrote: > > I think we should accept the reaper project as is and make that cassandra > management process 1.0, then integrate the netflix scheduler (and other new

Re: Proposing an Apache Cassandra Management process

I think we should accept the reaper project as is and make that cassandra management process 1.0, then integrate the netflix scheduler (and other new features) into that. The ultimate goal would be for the netflix scheduler to become the default repair scheduler, but I think using reaper as

Re: Reaper as cassandra-admin

eaper is also a consideration. On August 28, 2018 at 3:53:02 PM, dinesh.jo...@yahoo.com.INVALID (dinesh.jo...@yahoo.com.invalid) wrote: On Tuesday, August 28, 2018, 2:52:03 PM PDT, Blake Eggleston wrote: > I’m sure reaper will bring tech debt with it, but I doubt it's a hopeless > mess

Re: Reaper as cassandra-admin

I haven’t settled on a position yet (will have more time think about things after the 9/1 freeze), but I wanted to point out that the argument that something new should be written because an existing project has tech debt, and we'll do it the right way this time, is a pretty common software

Re: Proposing an Apache Cassandra Management process

I'd be more in favor of making it a separate project, basically for all the reasons listed below. I'm assuming we'd want a management process to work across different versions, which will be more awkward if it's in tree. Even if that's not the case, keeping it in a different repo at this point

Re: [VOTE] Release Apache Cassandra 3.0.17 (Take 2)

+1 On July 26, 2018 at 9:27:11 PM, Marcus Eriksson (krum...@gmail.com) wrote: +1 On Fri, Jul 27, 2018 at 5:03 AM Vinay Chella wrote: > +1 nb. > > Here are the test results. > https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.0.17_tentative > > Most of the failed tests are

Re: [VOTE] Release Apache Cassandra 2.2.13

+1 On July 26, 2018 at 9:26:48 PM, Marcus Eriksson (krum...@gmail.com) wrote: +1 On Fri, Jul 27, 2018 at 12:05 AM kurt greaves wrote: > +1 nb > > On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe, wrote: > > > +1 > > > > On 25 July 2018 at 08:17, Michael Shuler wrote: > > > > > I

Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

+1 On July 26, 2018 at 9:27:27 PM, Marcus Eriksson (krum...@gmail.com) wrote: +1 On Fri, Jul 27, 2018 at 4:59 AM Vinay Chella wrote: > +1 nb. > > Here are the failed tests (circleci > < > https://circleci.com/gh/vinaykumarchella/workflows/cassandra/tree/3.11.3_tentative > > >), >

Re: In need of reviewers

I'll spend a day or two working through some of these next week. On 5/11/18, 3:44 AM, "kurt greaves" wrote: We've got a bunch of tickets that are either in need of review or just a bit of feedback. Would be very grateful for any help here :). Bugs:

Re: Repair scheduling tools

g the lines of "don't repair >> when >> > > the compaction queue is too long" might make more sense. Blacklisted >> > > timeslots might be useful for avoiding peak time or batch jobs, but >> only if >> > > they can be spec

Re: Roadmap for 4.0

I agree that not releasing semi-regularly is not good for the project. I think our habit of releasing half working software is much worse though. Our testing/stability story is not iron clad. I really think the bar for releasing 4.0 should be that the people in this thread are running the code

Re: Roadmap for 4.0

+1 On 4/4/18, 5:48 PM, "Jeff Jirsa" wrote: Earlier than I’d have personally picked, but I’m +1 too -- Jeff Jirsa > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote: > > Top-posting as I think this summary is

Repair scheduling tools

Hi dev@, The question of the best way to schedule repairs came up on CASSANDRA-14346, and I thought it would be good to bring up the idea of an external tool on the dev list. Cassandra lacks any sort of tools for automating routine tasks that are required for running clusters,

Re: A JIRA proposing a seperate repository for the online documentation

It would probably be more productive to list some specific concerns you have with Hugo. Then explain why you think they make using it a bad idea. Then offer some alternatives. On 3/16/18, 1:18 PM, "Kenneth Brotman" wrote: Thanks for that Eric Evans.

Re: Expensive metrics?

Hi Micke, This is really cool, thanks for taking the time to investigate this. I believe the metrics around memtable insert time come in handy in identifying high partition contention in the memtable. I know I've been involved in a situation over the past year where we got actionable info from

Re: Reviewer for LWT bug

I'll take it On December 17, 2017 at 3:48:04 PM, kurt greaves (k...@instaclustr.com) wrote: Need a reviewer for CASSANDRA-14087 Pretty straight forward, we just get an NPE when comparing against a frozen collection which is null and we

Re: Cassandra pluggable storage engine (update)

Hi Dikang, Cool stuff. 2 questions. Based on your presentation at ngcc, it seems like rocks db stores things in byte order. Does this mean that you have code that makes each of the existing types byte comparable, or is clustering order implementation dependent? Also, I don't see anything in

Re: Proposal to retroactively mark materialized views experimental

The remaining issues are: * There's no way to determine if a view is out of sync with the base table. * If you do determine that a view is out of sync, the only way to fix it is to drop and rebuild the view. * There are liveness issues with updates being reflected in the view. On October 3,

Re: Proposal to retroactively mark materialized views experimental

(c) USING 'org.apache.cassandra.index.sasi.SASIIndex'; Warnings : A SASI index was enabled for ‘ks.sasi_table'. SASI is still experimental, take extra caution when using it in production. cqlsh:ks> -Jeremiah > On Oct 2, 2017, at 5:05 PM, Blake Eggleston <beggles...@apple.com> wrote: &g

Re: Proposal to retroactively mark materialized views experimental

does emitting a native protocol warning reduce visibility during > the > > >> development process? If you run CREATE MV and cqlsh then prints out a > > >> giant warning statement about how it is an experimental feature I > think > > >> that is pretty visibl

Re: Proposal to retroactively mark materialized views experimental

Yeah, I'm not proposing that we disable MVs in existing clusters. On October 2, 2017 at 10:58:11 AM, Aleksey Yeshchenko (alek...@apple.com) wrote: The idea is to check the flag in CreateViewStatement, so creation of new MVs doesn’t succeed without that flag flipped. Obviously, just

Re: Proposal to retroactively mark materialized views experimental

Yeah I’m not sure that just emitting a warning is enough. The point is to be super explicit that bad things will happen if you use MVs. I would (in a patch release) disable MV CREATE statements, and emit warnings for ALTER statements and on schema load if they’re not explicitly enabled. Only

Re: Proposal to retroactively mark materialized views experimental

strong feedback loop, we're going to face again the same issues and same debate in the future On Sun, Oct 1, 2017 at 5:30 PM, Blake Eggleston <beggles...@apple.com> wrote: > I'm not sure the main issue in the case of MVs is testing. In this case it > seems to be that there are some desi

Re: Proposal to retroactively mark materialized views experimental

xperimental flags in general as well, +1 > > >>> > > >>> > > >>> > > >>>> On Fri, 29 Sep 2017 at 13:22 Jon Haddad <j...@jonhaddad.com> wrote: > > >>>> > > >>>> I’m very much +1 on this,

Proposal to retroactively mark materialized views experimental

Hi dev@, I’d like to propose that we retroactively classify materialized views as an experimental feature, disable them by default, and require users to enable them through a config setting before using. Materialized views have several issues that make them (effectively) unusable in

Re: Proposal: Closing old, unable-to-repro JIRAs

+1 to that On September 14, 2017 at 4:50:54 PM, Jeff Jirsa (jji...@gmail.com) wrote: There's a number of JIRAs that are old - sometimes very old - that represent bugs that either don't exist in modern versions, or don't have sufficient information for us to repro, but the reporter has gone

  1   2   >