Consistency improvement idea for cutting down on the new user ramp up time.

I posted this Jira here already https://issues.apache.org/jira/browse/CASSANDRA-13315 but I wanted to toss it out there on the mailing list at the same time to get some broader feedback. I've been supporting users a few years and during that time I've had 2-5 conversations a week about what is

Re: [VOTE] Release Apache Cassandra 3.0.12

+1 (non-binding) On 2017-03-07 17:15, Michael Shuler wrote: I propose the following artifacts for release as 3.0.12. This release addresses a possible 2.1->3.0 upgrade issue[3], along with a few fixes committed since 3.0.11. sha1: 50560aaf0f2d395271ade59ba9b900a84cae70f1 Git:

Testing and jira tickets

Hey all, A nice convention we've stumbled into wrt to patches submitted via Jira is to post the results of unit test and dtest runs to the ticket (to show the patch doesn't break things). Many contributors have used the DataStax-provided cassci system, but that's not the best long term solution.

Re: Testing and jira tickets

No problem, I'll start a new thread. On Thu, Mar 9, 2017 at 11:48 AM Jason Brown wrote: > Jon and Brandon, > > I'd actually like to narrow the discussion, and keep it focused to my > original topic. Those are two excellent topics that should be addressed, > and the

Re: Testing and jira tickets

If you don't mind, I'd like to broaden the discussion a little bit to also discuss performance related patches. For instance, CASSANDRA-13271 was a performance / optimization related patch that included *zero* information on if there was any perf improvement or a regression as a result of the

committing performance patches without performance numbers

I'd like to discuss what I consider to be a pretty important matter - patches which are written for the sole purpose of improving performance without including a single performance benchmark in the JIRA. My original email was in "Testing and Jira Tickets", i'll copy it here for posterity: If you

Re: Testing and jira tickets

Jon and Brandon, I'd actually like to narrow the discussion, and keep it focused to my original topic. Those are two excellent topics that should be addressed, and the solution(s) might be the same or similar as the outcome of this. However, I feel they deserve their own message thread. Thanks

Re: committing performance patches without performance numbers

Hi, I agree that patch could have used it and it was amenable to micro-benchmarking. Just to be pedantic about process which is something I approve of to the chagrin of so many. On a completely related note that change also randomly boxes a boolean. Ariel On Thu, Mar 9, 2017, at 03:45 PM,

Re: Testing and jira tickets

Hi, Before this change I had already been queuing the jobs myself as a reviewer. It also happens to be that many reviewers are committers. I wouldn't ask contributors to run the dtests/utests for any purpose other then so that they know the submission is done. Even if they did and they pass it

Re: committing performance patches without performance numbers

I don't expect everyone to run a 500 node cluster off to the side to test their patches, but at least some indication that the contributor started Cassandra on their laptop would be a good sign. The JIRA I referenced was an optimization around List, Set and Map serialization. Would it really

Re: committing performance patches without performance numbers

Agree. Anything that's meant to increase performance should demonstrate it actually does that. We have microbench available in recent versions - writing a new microbenchmark isn't all that onerous. Would be great if we had perf tests included in the normal testall/dtest workflow for ALL patches so

Re: committing performance patches without performance numbers

Hi, I think there are issues around the availability of hardware sufficient to demonstrate the performance concerns under test. It's an open source project without centralized infrastructure. A lot of performance contributions come from people running C* in production. They are already running

Re: committing performance patches without performance numbers

Hi, I should clarify. Should in the sense of it was fine for the process we had at the time (ugh!) but it's not what we should do in the future. Ariel On Thu, Mar 9, 2017, at 04:55 PM, Ariel Weisberg wrote: > Hi, > > I agree that patch could have used it and it was amenable to >

Re: Testing and jira tickets

To Ariel's point, I don't think we can expect all contributors to run all utesss/dtests, especially when the patch spans multiple branches. On that front, I, like Ariel and many others, typically create our own branch of the patch and have executed the tests. I think this is a reasonable system,

Re: committing performance patches without performance numbers

After looking at the patch, my thoughts (beware, it's getting very technical): Original code: -t = new ListType(elements, isMultiCell); -ListType t2 = internMap.putIfAbsent(elements, t); -t = (t2 == null) ? t : t2; Optimized code: +t =

Re: [VOTE PASSED] Release Apache Cassandra 3.0.12

With 7 binding and 2 non-binding +1 votes, the release of 3.0.12 has passed. I'll get the artifacts uploaded first thing in the morning, since it's a bit late tonight. -- Warm regards, Michael On 03/07/2017 10:15 AM, Michael Shuler wrote: > I propose the following artifacts for release as