[DISCUSS] CEP-46 Finish Transient Replication/Witnesses

Hi all, The CEP is available here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=353601959 We would like to propose CEP-46: Finish Transient Replication/Witnesses for adoption by the community. CEP-46 would rename transient replication to witnesses and leverage mutation trac

Re: Fix versions for CASSANDRA-19596 improve IntervalTree build throughput

ined current test coverage and robust >>> property-based additions to the testing in 19596. >>> >>>> Early open which is enabled by default >>> Is it fair to assume most current C* nodes will no longer be on spinning >>> disk and thus we

Fix versions for CASSANDRA-19596 improve IntervalTree build throughput

Hi, I want to discuss what versions we should backport IntervalTree improvements to specifically 19596 which I think is the lower risk option because it builds the same trees as before. I think we should at least backport to 5.0. IntervalTree performance has shown up as a problematic bottleneck

Re: Merging compaction improvements to 5.0

Whoops, 5 months ago, not six months ago. Much more reasonable to be making this kind of fix. On Wed, Feb 19, 2025, at 3:56 PM, Ariel Weisberg wrote: > Hi, > > This does not constitute a review, but I looked at both of them to convince > myself how they go about solving thei

Re: Merging compaction improvements to 5.0

Hi, This does not constitute a review, but I looked at both of them to convince myself how they go about solving their respective problems is a good idea. I am weakly +1. The risk reward is there, but 13 months since 5.0 was released feels a little late to trying to improve node density instead

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Sorry I didn’t see on my phone this has already been brought up. On Fri, Feb 14, 2025, at 9:17 PM, Ariel Weisberg wrote: > Hi, > > This is already specified in SQL. Columns that aren’t nullable need > either to have a default value or a value specified in each > insert/update.

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Hi, This is already specified in SQL. Columns that aren’t nullable need either to have a default value or a value specified in each insert/update. Unless I am wrong about the standard or there is a persuasive reason to deviate from the standard I would argue this is actually a bug. A persuasiv

Re: [VOTE] CEP-45: Mutation Tracking

+1 On Mon, Feb 3, 2025, at 1:33 PM, Blake Eggleston wrote: > Hi dev@, > > I’d like to start the voting for CEP-45: Mutation Tracking > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking > Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m

Re: [DISCUSS] Bracing style on trunk

Hi, I do not care what bracing style we use. I do have a preferred one, but I don't care which one we use. I hate that we have check style, but not a gofmt equivalent. I would take any amount of churn pain to have a gofmt equivalent so I could stop thinking about style. I would not want the c

Re: [DISCUSS] Usage of "var" instead of types in the code

Hi, I don’t like `var` anywhere. Even if IntelliJ could automatically insert the concrete type it would still be a problem in the GH compare view. GH compare view is a real problem, because any time something is sufficiently obfuscated I have to bounce back and forth with an IDE, check out the

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Hi, > I just don't understand what "good enough performance" is. Should really specify throughput. There is a single thread writing records to the log and it's a bottleneck around a few hundred thousand entries/sec and 1gb/sec. It doesn't scale to arbitrary throughput requirements. > What is a

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Hi, A bit late to this discussion, there are few emails in the thread I'll respond to separately. Yes it's just to implement a binary file based queue that supports realtime tailing. If it had been low friction it would have made more sense, but given the friction Chronicle's approach to OSS b

Re: [DISCUSS] Replace airlift/airline library with Picocli

e enough justification to fix the obvious problem - if > it’s unmaintained, let’s remove it before we’re doing it on fire. > > > >> On Jul 16, 2024, at 8:11 AM, Ariel Weisberg wrote: >> >> Hi, >> >> I am pretty torn down the middle on this one. Unmaintai

Re: [CASSANDRA-19651][Review] idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied

Hi, I'll take a look. Thanks! Ariel On Wed, Jul 10, 2024, at 7:18 AM, Dmitry Konstantinov wrote: > Hello All, > > I recently submitted a patch what addresses a bug in idealCLWriteLatency > metric calculation: https://issues.apache.org/jira/browse/CASSANDRA-19651 > > Could someone help with re

Re: [DISCUSS] Replace airlift/airline library with Picocli

Hi, I am pretty torn down the middle on this one. Unmaintained bad, but also Aleksey is right. If there are few/no dependencies in airline then it could be "done" given the narrow scope of what it does. It seems to depend on Guava, javax.inject, and findbugs. Seems like we can probably update

Re: [VOTE] CEP-42: Constraints Framework

Hi, I am +1 on CEP-42 with the latest updates to the CEP to clarify syntax, error messages, constraint naming and generated naming, alter/drop, describe etc. I think this now tracks very closely to how other SQL databases define constraints and the syntax is easily extensible to multi-column an

Re: [DISCUSS] CEP-42: Constraints Framework

those application > level constraints that Doug mentions in an more accesible way than having to > configure such specific guardrais. > > For the addition of the CHECK keyword, I'm definitely not opposed to it if it > helps Cassandra users coming from other databases un

Re: [DISCUSS] CEP-42: Constraints Framework

Hi, I see a vote for this has been called. I should have provided more prompt feedback sooner. I am a strong +1 on adding column level constraints being a good thing to add. I'm not too concerned about row/partition/table level constraints, but I would like to change the syntax before I would

Re: [DISCUSS] Increments on non-existent rows in Accord

condition was met but couldn't update a non-existent row), or > CONDITION_NOT_MET > > > On Mon, Jun 24, 2024 at 11:42 AM Ariel Weisberg wrote: >> __ >> Hi, >> >> I think the current behavior maps to SQL more than CQL. In SQL an update >>

Re: [DISCUSS] Increments on non-existent rows in Accord

Hi, I think the current behavior maps to SQL more than CQL. In SQL an update doesn't generate an error if the row to be updating doesn't exist it just return 0 rows updated. If someone wanted an upsert or increment behavior in their transaction could they accomplish it with the current transa

Re: [DISCUSS] Stream Pipelines on hot paths

+1. To not using streams in hot paths. Regarding string concatenation in logging, for debug and trace it makes sense to avoid concatenation. For info and error I don't think it matters and it can be more concise to concatenate. It's not a big deal to standardize on one just because the extra ve

Re: CCM and CASSANDRA_USE_JDK11

that they run the same set of tests in >>> as similar environments as possible >> Yeah, I took a superset of circle and ASF tests to try and run >> :allthethings:. Part of how the checkstyle dependency check got in the way >> too, since we weren't running that

Re: CCM and CASSANDRA_USE_JDK11

Hi, There is definitely a mismatch between how the full range of dtests work and the direction CCM is going in and we have some difficulty getting those to match. I fully empathize with several of those CI systems not being publicly visible/accessible, and the behavior of upgrade paths being ab

Re: [DISCUSS] ccm as a subproject

Hi, Strong +1 as well. It's a pretty critical dependency in the path of testing and committing changes. Supporting integration points for alternative distributions of Cassandra is something I think we should generally be supportive as it's generally an opportunity to make things more modular an

Re: discuss: add to_human_size function

Hi, I think it’s a good quality of life improvement, but I am someone who believes in a rich set of built-in functions being a good thing. A format function is a bit more scope and kind of orthogonal. It would still be good to have shorthand functions for things like size. Ariel On Tue, Apr 9

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

Hi, If there is a faster/better way to replace a node why not have Cassandra support that natively without the sidecar so people who aren’t running the sidecar can benefit? Copying files over a network shouldn’t be slow in C* and it would also already have all the connectivity issues solved.

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

🥳🎉 Thanks for your work on this. Excited to have an easier way to write tests that leverage schema and data that also covers more. Ariel On Sat, Dec 23, 2023, at 9:17 AM, Alex Petrov wrote: > Thanks everyone, Harry is now in tree! Of course, that's just a small > milestone, hope it'll prove as

Re: [DISCUSS] CEP-39: Cost Based Optimizer

Hi, I am burying the lede, but it's important to keep an eye on runtime-adaptive vs planning time optimization as the cost/benefits vary greatly between the two and runtime adaptive can be a game changer. Basically CBO optimizes for query efficiency and startup time at the expense of not handli

Re: Future direction for the row cache and OHC implementation

Hi, Thanks for the generous offer. Before you do that can you give me a chance to add back support for Caffeine for the row cache so you can test the option of switching back to an on-heap row cache? Ariel On Thu, Dec 14, 2023, at 9:28 PM, Jon Haddad wrote: > I think we should probably figure

Re: Future direction for the row cache and OHC implementation

gt;>> So, unless it is being widely used by someone else outside of the >>> community (which it doesn't seem to be), from a maintenance and >>> integration testing perspective I think it would be better to keep the >>> ohc in-tree, so we will be aware of any i

Re: Future direction for the row cache and OHC implementation

Hi, To add some additional context. The row cache is disabled by default and it is already pluggable, but there isn’t a Caffeine implementation present. I think one used to exist and could be resurrected. I personally also think that people should be able to scratch their own itch row cache w

Future direction for the row cache and OHC implementation

Hi, Now seems like a good time to discuss the future direction of the row cache and its only implementation OHC (https://github.com/snazy/ohc). OHC is currently unmaintained and we don’t have the ability to release maven artifacts for it or commit to the original repo. I have reached out to the

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

Hi, Support for multiple storage backends including remote storage backends is a pretty high value piece of functionality. I am happy to see there is interest in that. I think that `ChannelProxyFactory` as an integration point is going to quickly turn into a dead end as we get into really usin

Re: [DISCUSS] Lift MessagingService.minimum_version to 40 in trunk

Hi, I am pretty strongly in favor just to keep the amount of code kept around for serialization/deserialization and caching serialized sizes for different versions under control. 5.0 will have changes necessitating using another version so it will be adding to the clutter. Ariel On Mon, Mar

Re: Welcome Patrick McFadin as Cassandra Committer

Welcome Patrick! Thank you for your years of contributions to the community. On Thu, Feb 2, 2023, at 12:58 PM, Benjamin Lerer wrote: > The PMC members are pleased to announce that Patrick McFadin has accepted > the invitation to become committer today. > > Thanks a lot, Patrick, for everything yo

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 On Mon, Feb 6, 2023, at 11: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: > https://lists.apache.org/thread/h25skwkbdztz9

Re: CASSANDRA-14482

Hi, I am +1 since it's an additional compressor and not the default. Ariel On Fri, Feb 15, 2019, at 11:41 AM, Dinesh Joshi wrote: > Hey folks, > > Just wanted to get a pulse on whether we can proceed with ZStd support. > The consensus on the ticket was that it’s a very valuable addition > wit

Re: cqlsh tests and Python 3

Hi, Do you mean Python 2/3 compatibility? This has been discussed earlier and I think that being compatible with both is an easier sell. Ariel > On Feb 11, 2019, at 1:24 PM, dinesh.jo...@yahoo.com.INVALID > wrote: > > Hey all, > We've gotten the cqlsh tests running in the Cassandra repo (t

Re: [VOTE] Release Apache Cassandra 3.11.4

73-L174> > > Let me know if this looks good to you, I will send a patch to > cassandra-dtest > > > > Thanks, > Vinay Chella > > > On Wed, Feb 6, 2019 at 8:07 PM Vinay Chella wrote: > > > Hi Ariel, > > > > Sure, I am volunteering to de

Re: [VOTE] Release Apache Cassandra 3.11.4

Hi, It fails consistently. I don't know why the data is not evenly distributed. Can someone volunteer to debug this failing test to make sure there isn't an issue with bootstrap in 3.11? https://circleci.com/gh/aweisberg/cassandra/2593 Thanks, Ariel On Wed, Feb 6, 2019, at 3:11

Re: [VOTE] Release Apache Cassandra 3.11.4

Hi, -0 bootstrap_upgrade_test.py test_simple_bootstrap_mixed_versions fails because it doesn't see the expected on disk size within 30% of the expected value. It's bootstrapping a new version node and runs cleanup on the existing node. If the data were evenly distributed the on disk size shoul

Re: [VOTE] Release Apache Cassandra 3.0.18

Hi, +1 Upgrade test look OK. There are failures I also found against 2.2 plus some other test bugs. Nothing that looks like a product bug. https://circleci.com/gh/aweisberg/cassandra/2589 Ariel On Wed, Feb 6, 2019, at 5:02 AM, Marcus Eriksson wrote: > +1 > > Den ons 6 feb. 2019 kl 10:53 skrev

Re: [VOTE] Release Apache Cassandra 2.2.14

Hi, +1 Upgrade tests: https://circleci.com/gh/aweisberg/cassandra/2587 Known issue https://issues.apache.org/jira/browse/CASSANDRA-14155 which is not a blocker There is a test failure on a thrift connection not being open. Might be test bug. If it's a product bug it's probably not that seriou

Re: [VOTE] Release Apache Cassandra 2.2.14

Hi, Can we also run the upgrade tests? We should do that as part of the release process. I can do that tomorrow. Ariel On Tue, Feb 5, 2019, at 1:11 PM, Joseph Lynch wrote: > 2.2.14-tentative unit and dtest run: > https://circleci.com/gh/jolynch/cassandra/tree/2.2.14-tentative > > unit tests: 0

Re: Implementing an Abstract Replication Strategy

Hi, Cassandra expects a replication strategy to accept a description of a consistent hash ring and then use that description to determine what ranges on the consistent hash ring each node replicates. If you implement the API those operations should all just work. I'm not sure what the implici

Re: Git Repo Migration

+1 On Fri, Jan 4, 2019, at 5:49 AM, Sam Tunnicliffe wrote: > As per the announcement on 7th December 2018[1], ASF infra are planning > to shutdown the service behind git-wip-us.apache.org and migrate all > existing repos to gitbox.apache.org > > There are further details in the original mail,

Re: [VOTE] Change Jira Workflow

+1 On Mon, Dec 17, 2018, at 10:19 AM, Benedict Elliott Smith wrote: > I propose these changes > * > > to the Jira Workflow for the project. The vote will be open for 72 > hours**. > > I am, of course, +1. > > * W

Re: Revisit the proposal to use github PR

t well, unless there's some > technique I and perhaps others are unaware of. > > On Thu, Dec 13, 2018 at 9:47 AM Ariel Weisberg wrote: > > > Hi, > > > > I'm not clear on what github makes worse. It preserves more history then > > the JIRA approach. When p

Re: Revisit the proposal to use github PR

Hi, I'm not clear on what github makes worse. It preserves more history then the JIRA approach. When people invitably force push their branches you can't tell from the link to a branch on JIRA. Github preserves the comments and force push history so you know what version of the code each commen

Re: JIRA Workflow Proposals

Hi, Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged. 1. E, D, C, B, A 2. B, C, A 3. A 4. -.5 Ariel On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote: > Hi, > > Sorry I was just slow on the uptake as to what auto-populate meant RE #2. > &g

Re: JIRA Workflow Proposals

e I don't think it's that harmful either. Ariel On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote: > On 10 Dec 2018, at 16:21, Ariel Weisberg wrote: > > > > Hi, > > > > RE #1, does this mean if you submit a ticket and you are not a contributor >

Re: JIRA Workflow Proposals

ack Ariel’s dissenting view. > > My votes are: > 1: +1 > 2: B,C,A > 3: A > 4: +0.5 > > > For tracking, the new consensus from the prior vote is: > 1: A (+10) > 2: +9 -0.1 > 3: +10 > 4: +6 -2 (=+4) > 5: +2; a lot of meh. > 6: +9 > > > > > On 7

Re: JIRA Workflow Proposals

> > > > On 7 Dec 2018, at 17:52, Ariel Weisberg wrote: > > > > Hi, > > > > Late but. > > No harm in them continuing to roll in, I’m just cognisant of needing to > annoy everyone with a second poll, so no point perpetuating it past a > likely una

Re: JIRA Workflow Proposals

Hi, Late but. 1. A 2. +1 3. +1 4. -1 5. -0 6. +1 RE 4, I think blocker is an important priority. High and urgent mean the same thing to me. Wish is fine, but that is too similar to low if you ask me. My ideal would be low, medium, high, blocker. Medium feels weird, but it's a real thing, it's

Re: Request to review feature-freeze proposed tickets

Hi, I would like to get as many of these as is feasible in. Before the feature freeze started 1 out of 17 JIRAs that were patch available were reviewed and committed. If you didn’t have access reviewers and committers, as the one out of the 17 did, it has been essentially impossible to get you

Re: Implicit Casts for Arithmetic Operators

we will hopefully minimise surprise to operators this way. >> >> If people largely agree, I will call a vote, and we can pick up a couple >> of more focused discussions afterwards on how we interpret the leeway it >> gives. >> >> >>> On 12 Oct 2

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Use a more space efficient representation for compressed chunk offsets" for post 4.0. Regards, Ariel On Tue, Oct 23, 2018, at 11:46 AM, Ariel Weisberg wrote: > Hi, > > To summarize who we have heard from so far > > WRT to changing just the default: > > +1: > Jon H

Re: Proposed changes to CircleCI testing workflow

Hi, Thank you for working on this. These all sound like good changes to me. Ariel On Fri, Oct 26, 2018, at 10:49 AM, Stefan Podkowinski wrote: > I'd like to give you a quick update on the work that has been done > lately on running tests using CircleCI. Please let me know if you have > any objec

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Hi, I just asked Jeff. He is -0 and -0.5 respectively. Ariel On Tue, Oct 23, 2018, at 11:50 AM, Benedict Elliott Smith wrote: > I’m +1 change of default. I think Jeff was -1 on that though. > > > > On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: > > > > Hi, &

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Hi, To summarize who we have heard from so far WRT to changing just the default: +1: Jon Haddadd Ben Bromhead Alain Rodriguez Sankalp Kohli (not explicit) -0: Sylvaine Lebresne Jeff Jirsa Not sure: Kurt Greaves Joshua Mckenzie Benedict Elliot Smith WRT to change the representation: +1: Ther

Re: CASSANDRA-13241 lower default chunk_length_in_kb

5:20 64k 25:33 32k 20:01 16k 19:19 16k 19:14 8k 16:51 4k 15:39 Ariel On Thu, Oct 18, 2018, at 2:55 PM, Ariel Weisberg wrote: > Hi, > > For those who were asking about the performance impact of block size on > compr

Re: CASSANDRA-13241 lower default chunk_length_in_kb

at 5:32 AM, Benedict Elliott Smith wrote: > FWIW, I’m not -0, just think that long after the freeze date a change > like this needs a strong mandate from the community. I think the change > is a good one. > > > > > > > On 17 Oct 2018, at 22:09, Ariel Weisberg wrote:

Re: CASSANDRA-13241 lower default chunk_length_in_kb

s a > > consensus here as well, > > > > C*heers, > > --- > > Alain Rodriguez - al...@thelastpickle.com > > France / Spain > > > > The Last Pickle - Apache Cassandra Consulting > > http://www.thelastpickle.com > > >

Re: CASSANDRA-13241 lower default chunk_length_in_kb

the small size and the large > > improvement to new users experience (as long as we are explicit in the > > documentation about memory consumption). > > > > > >> On Thu, Oct 11, 2018 at 7:11 PM Ariel Weisberg wrote: > >> > >> Hi, > >>

Re: Implicit Casts for Arithmetic Operators

perand always be the > return type. > > This would still leave a decision for float+double, though. The most > consistent behaviour with that stated above would be to always take the > most approximate type to return (i.e. float), but this would seem to me > to be fairl

Re: Implicit Casts for Arithmetic Operators

Hi, I agree with what's been said about expectations regarding expressions involving floating point numbers. I think that if one of the inputs is approximate then the result should be approximate. One thing we could look at for inspiration is the SQL spec. Not to follow dogmatically necessaril

Re: Tested to upgrade to 4.0

Hi, Thanks for reporting this. I'll get this fixed today. Ariel On Fri, Oct 12, 2018, at 7:21 AM, Tommy Stendahl wrote: > Hi, > > I tested to upgrade to Cassandra 4.0. I had an existing cluster with > 3.0.15 and upgraded the first node but it fails to start due to a > NullPointerException. >

CASSANDRA-13241 lower default chunk_length_in_kb

Hi, This is regarding https://issues.apache.org/jira/browse/CASSANDRA-13241 This ticket has languished for a while. IMO it's too late in 4.0 to implement a more memory efficient representation for compressed chunk offsets. However I don't think we should put out another release with the current

Re: Implicit Casts for Arithmetic Operators

> changes to go unnoticed on a JIRA, and then ossify. > > > > On 2 Oct 2018, at 15:48, Ariel Weisberg wrote: > > > > Hi, > > > > I think we should decide based on what is least surprising as you mention, > > but isn't overridden by some o

Re: Implicit Casts for Arithmetic Operators

Hi, I think we should decide based on what is least surprising as you mention, but isn't overridden by some other concern. It seems to me the priorities are * Correctness * Performance * User visible complexity * Developer visible complexity Defaulting to silent implicit data loss is not ideal

Re: Recommended circleci settings for DTest

/development/testing.rst#circleci > > > > On Fri, Sep 28, 2018 at 2:55 PM Ariel Weisberg wrote: > > > Hi, > > > > Apply the following diff and if you have access to the higher memory > > containers it should run the dtests with whatever you have. You may need t

Re: Recommended circleci settings for DTest

Hi, Apply the following diff and if you have access to the higher memory containers it should run the dtests with whatever you have. You may need to adjust parallelism to match whatever you paid for. diff --git a/.circleci/config.yml b/.circleci/config.yml index 5a84f724fc..76a2c9f841 100644 --

Re: Request for post-freeze merge exception

+1 Transient Replication had some rebase pain as well, but we were able to get through it at the last minute. The traffic on the last few days was pretty heavy with several substantial commits. On Tue, Sep 4, 2018, at 2:19 PM, Jeff Jirsa wrote: > Seems like a reasonable thing to merge to me. Not

Re: Transient Replication 4.0 status update

rent nodes? Admittedly > > I'm not familiar with how much work has gone into fixing cluster expansion > > with vnodes, it is my understanding that you typically expand only one node > > at a time or in multiples of the datacenter size > > > > On Mon, Aug 27, 2018

Re: Transient Replication 4.0 status update

#x27;m not familiar with how much work has gone into fixing cluster expansion > with vnodes, it is my understanding that you typically expand only one node > at a time or in multiples of the datacenter size > > On Mon, Aug 27, 2018 at 12:29 PM Ariel Weisberg wrote: > > > Hi al

Transient Replication 4.0 status update

Hi all, I wanted to give everyone an update on how development of Transient Replication is going and where we are going to be as of 9/1. Blake Eggleston, Alex Petrov, Benedict Elliott Smith, and myself have been working to get TR implemented for 4.0. Up to now we have avoided merging anything r

Re: upgrade guava on trunk before 9/1?

r at least two years from now. > > As I asked, "does anybody feeling strongly?". Personally, I'm sorta +0 to > +0.5, but I was just throwing this out there in case someone does really > think it best we upgrade (and wants to make a contribution). > > -Jason > >

Re: upgrade guava on trunk before 9/1?

Hi, What do we get from Guava in exchange for upgrading? Ariel On Wed, Aug 15, 2018, at 10:19 AM, Jason Brown wrote: > Hey all, > > Does anyone feel strongly about upgrading guava on trunk before the 9/1 > feature freeze for 4.0? We are currently at 23.3 (thanks to > CASSANDRA-13997), and the c

Re: GitHub PR ticket spam

Hi, Great idea. +1 to moving it to the work log. Thanks, Ariel On Mon, Aug 6, 2018, at 12:40 PM, Aleksey Yeshchenko wrote: > Nice indeed. I assume it also doesn’t spam commits@ when done this way, > in which case double +1 from me. > > — > AY > > On 6 August 2018 at 17:18:36, Jeremiah D Jorda

Re: GitHub PR ticket spam

Hi, I really like having it mirrored. I would not be in favor of eliminating automated mirroring. What we are seeing is that removing the pain of commenting in JIRA is encouraging people to converse more in finer detail. That's a good thing. I have also seen the pain of how various github work

Re: Improve the performance of CAS

Hi, I think you are looking at the right low hanging fruit. Cassandra deserves a better consensus protocol, but it's a very big project. Regards, Ariel On Wed, May 16, 2018, at 5:51 PM, Dikang Gu wrote: > Cool, create a jira for it, > https://issues.apache.org/jira/browse/CASSANDRA-14448. I hav

Re: Evolving the client protocol

contribute an Apache >> licensed thread per core implementation in Java that matches the protocol >> change and shard concept you are looking for ;P > > I doubt I'll survive the egregious top-posting that is going on in this list. > >> >> >>>

Re: Evolving the client protocol

ke a potential approach. > > > > This would give you a path forward at least for the short term. > > > > > > On Thu, Apr 19, 2018 at 12:10 PM Ariel Weisberg wrote: > > > >> Hi, > >> > >> I think that updating the protocol spec to Cassa

Re: Evolving the client protocol

from ScyllaDB de-risking protocol changes, but if no one commits to doing the work you might find we release the next protocol version without the tentative spec changes. Ariel On Thu, Apr 19, 2018, at 12:53 PM, Avi Kivity wrote: > > > On 2018-04-19 19:10, Ariel Weisberg wrote: >

Re: Evolving the client protocol

Hi, I think that updating the protocol spec to Cassandra puts the onus on the party changing the protocol specification to have an implementation of the spec in Cassandra as well as the Java and Python driver (those are both used in the Cassandra repo). Until it's implemented in Cassandra we ha

Re: Roadmap for 4.0

Hi, +1 to September 1st. I know I will have much better availability then. Ariel On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote: > +1 with Sept 1st as I am seeing willingness for people to test it after it > > > On Apr 12, 2018, at 13:59, Ben Bromhead wrote: > > > > While I would prefer

Re: Roadmap for 4.0

Hi, What is the role of minor releases in Cassandra? I know that we have guarantees we make about minor releases that we don't make about major releases (is this summarized anywhere?), but is there anyone who actually thinks those guarantees are worth it vs having major releases on a shorter sc

Re: Roadmap for 4.0

Hi, +1 to having a feature freeze date. June 1st is earlier than I would have picked. Ariel On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote: > +1 here for June 1. > > On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown wrote: > > > +1 > > > > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston >

Re: question on running cassandra-dtests

eDecorator.run(DefaultThreadFactory.java:138) [netty- > all-4.1.14.Final.jar:4.1.14.Final] > at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151], ERROR > [MessagingService-NettyOutbound-Thread-4-7] 2018-03-28 00:24:37,063 > OutboundHandshakeHandler.java:209 - Failed to properly handshake

Re: question on running cassandra-dtests

Hi, Great! Glad you were able to get up and running. The dtests can be tricky if you aren't already somewhat familiar with Python. Ariel On Mon, Mar 26, 2018, at 9:10 PM, Murukesh Mohanan wrote: > On Tue, Mar 27, 2018 at 6:47 Ariel Weisberg wrote: > > > Hi, > > > &

Re: question on running cassandra-dtests

? > > Thanks, > Preetika > > -Original Message- > From: Ariel Weisberg [mailto:ar...@weisberg.ws] > Sent: Monday, March 26, 2018 9:32 AM > To: dev@cassandra.apache.org > Subject: Re: question on running cassandra-dtests > > Hi, > > Your environment is python 2

Re: question on running cassandra-dtests

Hi, Your environment is python 2.7 when it should be python 3. See: > File "/usr/local/lib/python2.7/dist-packages/_pytest/assertion/ > rewrite.py", line 213, in load_module Are you using virtualenv to create a python 3 environment to use with the tests? >From README.md: **Note**: While virtu

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Hi, I'm not clear on what building and bundling our own JRE/JDK accomplishes? What is our source for JRE updates going to be? Are we going to build our own and does Oracle release the source for their LTS releases? Are we going to extract LTS updates from CentOS? If the goal of bundling is to

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

sary. It's not so difficult to update apt.source ;) > > 08:42:43 CI ? It just let's your test matrix explode - a litte ;) > > 08:46:48 Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8 > > (latest)'` in job DSL and could easily modify that > > > &g

Re: Debug logging enabled by default since 2.2

d go to > system.log. > > I guess in that configuration, some/most TRACE level loggings would then be > eligible to graduate to DEBUG...? > > > > > On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg wrote: > > > Hi, > > > > Signal to noise ratio

Re: Debug logging enabled by default since 2.2

Hi, Another point I want to mention. Another reason we separate the files is that they can then use separate log rolling policies. A verbose debug log no longer rolls the INFO level system.log. Ariel On Tue, Mar 20, 2018, at 12:19 PM, Ariel Weisberg wrote: > Hi, > > Signal to no

Re: Debug logging enabled by default since 2.2

Hi, Signal to noise ratio matters for logs. Things that we log at DEBUG aren't at all bound by constraints of human readability or being particularly relevant most of the time. I don't want to see most of this stuff unless I have already not found what I am looking for at INFO and above. Can w

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Hi, +1 to what Jordan is saying. It seems like if we are cutting a release off of trunk we want to make sure we get N years of supported JDK out of it. For a single LTS release N could be at most 3 and historically that isn't long enough and it's very likely we will get < 3 after a release is

Re: Debug logging enabled by default since 2.2

Hi, In a way the real issue might be that we don’t have nightly performance runs that would make an accidentally introduced debug statement obvious. A log statement that runs once or more per read or write should be easy to spot. I haven’t measured the impact though. And as a bonus by having th

Re: Making RF4 useful aka primary and secondary ranges

Hi, There is a JIRA for decoupling the size of the group size used for consensus with level of data redundancy. https://issues.apache.org/jira/browse/CASSANDRA-13442 It's been discussed quite a bit offline and I did a presentation on it at NGCC. Hopefully we will see some movement on it soon.

  1   2   >