Concurrent shouldn’t matter (they’re non-overlapping in the repro). And I’d personally be a bit surprised if table count matters that much. It probably just requires high core count and enough data that the streams actually interact with the rate limiter On Dec 11, 2022, at 10:32 AM, Mick Semb Weve
But it's not merge-than-review, because they've already been reviewed,
before being merged to the feature branch, by committers (actually PMC
members)?
You want code that's been written by one PMC member and reviewed by 2 other
PMC members to be put up for review by some random 4th party? For
Usually requires an offer to donate from the current owner, an acceptance
of that offer (PMC vote), and then the work to ensure that contributions
are acceptable from a legal standpoint (e.g. like the incubator -
https://incubator.apache.org/guides/transitioning_asf.html - "For
contributions compos
+1
On Mon, Feb 6, 2023 at 8:16 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/h25skwkbdztz9h
I'm not even convinced even 8110 addresses this - just writing sstables in
old versions won't help if we ever add things like new types or new types
of collections without other control abilities. Claude's other email in
another thread a few hours ago talks about some of these surprises -
"Specific
When people are serious about this requirement, they’ll build the downgrade equivalents of the upgrade tests and run them automatically, often, so people understand what the real gap is and when something new makes it break Until those tests exist, I think collectively we should all stop pretending
A huge number of people use this legal and unsafe combination - like anyone
running RF=3 in AWS us-west-1 (or any other region with only 2 accessible
AZs), and no patch is going to suddenly make that safe, and banning it
hurts users a lot.
If we're really going to ship a less-bad version of this,
Anyone have stats on how many people use RF > 3 per dc? (I know what it looks like in my day job but I don’t want to pretend it’s representative of the larger community) I’m a fan of fixing this but I do wonder how common this is in the wild. On Mar 7, 2023, at 9:12 AM, Derek Chen-Becker wrote:I
On Wed, Mar 8, 2023 at 5:25 AM Bowen Song via dev
wrote:
> At the moment, when a read error, such as unrecoverable bit error or data
> corruption, occurs in the SSTable data files, regardless of the
> disk_failure_policy configuration, manual (or to be precise, external)
> intervention is require
> On Mar 17, 2023, at 1:46 PM, Jeremy Hanna wrote:
>
>
>
> One much more graceful element of UCS is that instead of what was previously
> done with compaction strategies where the server just shuts down when running
> out of space - forcing system administrators to be paranoid about headro
the compaction. I didn't realize that
> LCS would try to reduce the scope of the compaction. I can't find in the
> branch where it handles that.
>
> Branimir, can you point to where it handles the scenario?
>
> Thanks,
>
> Jeremy
>
>>> On Mar 17, 2
On Tue, Mar 28, 2023 at 7:30 AM Jeremiah D Jordan
wrote:
> - Resources isolation. Having the said service running within the same JVM
> may negatively impact Cassandra storage's performance. It could be more
> beneficial to have them in Sidecar, which offers strong resource isolation
> guarantees
KEYSPACE at least makes sense in the context that it is the unit that
defines how those partitions keys are going to be treated/replicated
DATABASE may be ambiguous, but it's ambiguity shared across the industry.
Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
it'll be u
On Thu, Apr 27, 2023 at 7:39 AM Jonathan Ellis wrote:
> It's been a while, so I may be missing something, but do we already have
> fixed-size lists? If not, I don't see why we'd try to make this fit into a
> List-shaped problem.
>
We do not. The proposal got closed as wont-fix
https://issues.ap
Changes like this always scare me, but the benefits probably outweigh the
risks. Probably obviously to whoever implements but please make sure if
this happens is super visible in both NEWS and simultaneously updates the
to-string / to-cql representation of the schema in cqlsh / drivers /
snapshots
On Mon, Jun 12, 2023 at 9:50 AM Benjamin Lerer wrote:
> If you have rows that vary significantly in their size, your latencies
>> could end up being pretty unpredictable using a LIMIT BY . Being
>> able to specify a limit by bytes at the driver / API level would allow app
>> devs to get more dete
On Mon, Jun 12, 2023 at 10:18 AM Mick Semb Wever wrote:
>
>
> On Mon, 12 Jun 2023 at 15:02, Maxim Muzafarov wrote:
>
>> Hello everyone,
>>
>> I would like to make the source code of the Cassandra project more
>> visible to people outside of the Cassandra Community and highlight the
>> typical kn
+1
On Tue, Jun 13, 2023 at 7:15 AM Jeremy Hanna
wrote:
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of
> the donation. Nothing more.
> The plan is to introd
Either would be better than today.
On Thu, Jun 22, 2023 at 1:57 PM Jordan West wrote:
> Hi,
>
> I’m wondering if there is appetite to change the default SSL provider for
> Cassandra going forward to either ACCP [1] or tc-native in Netty? Our
> deployment as well as others I’m aware of make this
On Thu, Jun 22, 2023 at 11:23 PM Berenguer Blasi
wrote:
> Hi all,
>
> Given we're already introducing a new sstable format (OA) in 5.0 I would
> like to try to get this in before the freeze. The point being that
> sstables with lots of small partitions would benefit from a smaller DT
> at partiti
+1
On Mon, Jul 10, 2023 at 8:42 AM Josh McKenzie wrote:
> 2) keep it there in 5.0 but mark it @Deprecated
>
> I'd say Deprecate, log warnings that it's not supported nor maintained and
> people to use it at their own risk, and that it's going to be removed.
>
> That is, assuming the maintenance
Given the disclaimer, can you just confirm why we'd cut an alpha now -
we're trying to lock protocols and give other people an integration target,
presumably?
On Fri, Aug 25, 2023 at 8:14 AM Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
> DISCLAIMER,
Just to be clear - this repo?
https://github.com/haifengl/smile/blob/master/LICENSE
That shows GPL + Commercial?
On Wed, Sep 13, 2023 at 9:10 AM Brandon Williams wrote:
> I don't see any problem with this, +1.
>
> Kind Regards,
> Brandon
>
>
> On Wed, Sep 13, 2023 at 11:09 AM Mike Adamson
>
On Wed, Sep 13, 2023 at 9:25 AM Ekaterina Dimitrova
wrote:
> Jeff, isn’t this ok as long as it is used only in tests? If we are not
> sure we can open a Jira to legal?
>
> On Wed, 13 Sep 2023 at 12:23, Jeff Jirsa wrote:
>
>> Just to be clear - this repo?
>> ht
To do that, the cassandra PMC can open a legal JIRA and ask for a (durable,
concrete) opinion.
On Fri, Sep 22, 2023 at 5:59 AM Benedict wrote:
>
>1. my understanding is that with the former the liability rests on the
>provider of the lib to ensure it's in compliance with their claims to
- I think this is a great step forward.
- Being able to move sstables around between tiers of storage is a feature
Cassandra desperately needs, especially if one of those tiers is some sort
of object storage
- This looks like it's a foundational piece that enables that. Perhaps by a
team that's alr
Claude if you’re still at POC phase does it make sense for you to perhaps help validate / qualify the work that Henrik seems willing to rebase rather than reinventing the wheel? On Sep 26, 2023, at 11:23 PM, Claude Warren, Jr via dev wrote:I spent a little (very little) time building an S3 implem
+1
On Mon, Oct 2, 2023 at 9:53 PM Mick Semb Wever wrote:
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>
> The SGA has been sent to the ASF. This does not require acknowledgement
> before the vote.
>
On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever wrote:
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
I think this presumes that 5.0 GA is date driven instead
,
> but we'll grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understandin
-0 to cutting a beta we know has a very obvious correctness flaw with a fix
already understood
On Tue, Nov 28, 2023 at 10:40 AM Patrick McFadin wrote:
> JD, that wasn't my point. It feels like we are treating a beta like an RC,
> which it isn't. Ship Beta 1 now and Beta 2 later. We need people
I'm also torn on the CEP as presented. I think some of it is my negative
emotional response to the examples - e.g. I've literally never seen a real
use case where unfolding constants matters, and I'm trying to convince
myself to read past that.
I also cant tell what exactly you mean when you say "
> On Dec 14, 2023, at 1:51 PM, Dinesh Joshi wrote:
>
>
>>
>> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg wrote:
>>
>> 1. Fork OHC and start publishing under a new package name and continue to
>> use it
>
> Who would fork it? Where would you fork it? My first instinct is that this
> wo
The problem with generalizing things is if you’re behind on compaction, reads get expensive, so you pause compaction completely, you’re SOL and you’ll eventually have to throttle traffic to recoverThe SEDA model is bad at back pressure and deferred cost makes it non-obvious which resource to slow t
Auth is one of those things that needs to be a bit more concrete In the scenario you describe, you already have an option to deploy the auth in piece partially during the rollout (pause halfway through) in the cluster and look for asymmetric connections, and the option to drop in a new Authenticato
1) If there’s an “old compatible default” and “latest recommended settings”,
when does the value in “old compatible default” get updated? Never?
2) If there are test failures with the new values, it seems REALLY IMPORTANT to
make sure those test failures are discovered + fixed IN THE FUTURE TOO.
On 2024/02/21 09:26:53 Jarek Potiuk wrote:
> Hello dear Cassandra community,
>
> I am a fellow PMC member of Apache Airflow and recently we started to look
> at the Cassandra provider of ours in the context of Python 3.12 migration
> and the integration raised my interest.
>
> TL;DR; I am quit
I think Jordan and German had an interesting insight, or at least their comment made me think about this slightly differently, and I’m going to repeat it so it’s not lost in the discussion about zerocopy / sendfile.The CEP treats this as “move a live instance from one machine to another”. I know wh
Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going forward?
You can remove the shadowed values at compaction time, but you can’t ever fully
propagate the range update to point updates, so you’d be propagating all of the
range-update structures throughout everything forever. It’s JUST like a range
tombstone - you don’t know what it’s shadowing (and can’t,
Would this be implemented solely in the write path? Or would you also try to enforce it in the read and sstable/compaction/repair paths as well? On May 31, 2024, at 23:24, Bernardo Botella wrote:Hello everyone,I am proposing this CEP:CEP-42: Constraints Framework - CASSANDRA - Apache Software Fo
fourth seems incredibly unlikely. The third seems maybe possible, but why not spec out the full range with the CEP instead of assuming iterative implementation?On Jun 2, 2024, at 20:59, Jeff Jirsa wrote:Would this be implemented solely in the write path? Or would you also try to enforce it in the
If we have a public-facing API that we’re contemplating releasing to the
public, and we don’t think it’s needed, we should remove it before it’s
launched and we’re stuck with it forever.
> On Jun 20, 2024, at 9:55 AM, Jeremiah Jordan wrote:
>
> +1 from me for 1, just remove it now.
> I thi
+1
Thank you for being explicit about which authors of gocql have signed the ICLA
> Where The Gocql Authors for copyright purposes are below. Those marked with
> asterisk have agreed to donate (copyright assign) their contributions to the
> Apache Software Foundation, signing CLAs when appropriat
+1
> On Jun 25, 2024, at 5:04 AM, Mick Semb Wever wrote:
>
>
>
> Proposing the test build of Cassandra 5.0-rc1 for release.
>
> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.o
On Apr 20, 2018, at 5:03 AM, Sylvain Lebresne wrote:
>>
>>
>> Those were just given as examples. Each would be discussed on its own,
>> assuming we are able to find a way to cooperate.
>>
>>
>> These are relatively simple and it wouldn't be hard for use to patch
>> Cassandra. But I want to
spec is what the server implements. Anything we don’t implement can use the
arbitrary payload from the zipkin tracing ticket or fork.
--
Jeff Jirsa
> On Apr 23, 2018, at 6:18 PM, Nate McCall wrote:
>
> Folks,
> Before this goes much further, let's take a step back for a
They aren't even remotely similar, they're VERY different. Here's a few
starting points:
1) Most of Datastax's work for the first 5, 6, 8 years of existence focused
on driving users to cassandra from other DBs (see all of the "Cassandra
Summits" that eventually created trademark friction) ; Scylla
On Sat, Apr 28, 2018 at 4:49 AM, mck wrote:
> We should, as open source contributors, put business concerns to the side
> and welcome opportunities to work across company and product lines.
>
I resent the fact that you're calling this a business concern. This isn't a
business concern, and as a
Here's what's going on in the Cassandra world this spring:
Mailing list:
- Kurt sent out a call for reviewers:
https://lists.apache.org/thread.html/f1f7926d685b7f734edb180aeddc3014d79dc6e5f89e68b751b9eb5e@%3Cdev.cassandra.apache.org%3E
- Dinesh proposed a management sidecar:
https://lists.apache.o
Interesting!
I suspect I know what the increased disk usage in TWCS, and it's a solvable
problem, the problem is roughly something like this:
- Window 1 has sstables 1, 2, 3, 4, 5, 6
- We start compacting 1, 2, 3, 4 (using STCS-in-TWCS first window)
- The TWCS window rolls over
- We flush (sstable
This would matter for the base table, but would be less likely for the
secondary index, where the partition key is the value of the base row
Roman: there’s a config option related to only purging repaired tombstones - do
you have that enabled ? If so, are you running repairs?
--
Jeff Jirsa
Think he's talking about
https://issues.apache.org/jira/browse/CASSANDRA-6434
Doesn't solve every problem if you don't run repair at all, but if you're
not running repairs, you're nearly guaranteed problems with resurrection
after gcgs anyway.
On Thu, Jun 21, 2018 at 11:33 AM, Jay Zhuang wrote
+1
On Mon, Jul 2, 2018 at 1:11 PM, Michael Shuler
wrote:
> I propose the following artifacts for release as 3.11.3.
>
> sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd
> Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho
> rtlog;h=refs/tags/3.11.3-tentative
> Artifacts: https://rep
+1
On Mon, Jul 2, 2018 at 1:10 PM, Michael Shuler
wrote:
> I propose the following artifacts for release as 2.2.13.
>
> sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
> Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho
> rtlog;h=refs/tags/2.2.13-tentative
> Artifacts: https://rep
+1
On Mon, Jul 2, 2018 at 1:10 PM, Michael Shuler
wrote:
> I propose the following artifacts for release as 3.0.17.
>
> sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2
> Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho
> rtlog;h=refs/tags/3.0.17-tentative
> Artifacts: https://rep
I think there's value in the psychological commitment that if someone has
time to contribute, their contributions should be focused on validating a
release, not pushing future features.
On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad wrote:
> I agree with Josh. I don’t see how changing the conv
Yes?
--
Jeff Jirsa
> On Jul 3, 2018, at 2:29 PM, Jonathan Ellis wrote:
>
> Is that worth the risk of demotivating new contributors who might have
> other priorities?
>
>> On Tue, Jul 3, 2018 at 4:22 PM, Jeff Jirsa wrote:
>>
>> I think there's value i
Ultimately, we have a consensus driven development. If Jonathan or Dave
strongly disagrees with this, they can share their strong disagreement.
Jonathan shared his concern about dissuading contributors.
What's absurd is trying the same thing we've tried for 10 years and
expecting things to magica
+1
--
Jeff Jirsa
> On Jul 11, 2018, at 2:46 PM, sankalp kohli wrote:
>
> Hi,
>As discussed in the thread[1], we are proposing that we will not branch
> on 1st September but will only allow following merges into trunk.
>
> a. Bug and Perf fixes to 4.0.
> b. Crit
On Thu, Jul 12, 2018 at 10:54 AM, Michael Burman
wrote:
> On 07/12/2018 07:38 PM, Stefan Podkowinski wrote:
>
>> this point? Also, if we tell someone that their contribution will be
>> reviewed and committed later after 4.0-beta, how is that actually making
>> a difference for that person, compar
+1
On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler
wrote:
> I propose the following artifacts for release as 3.0.17.
>
> sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.17-tentative
> Artifacts:
> https
+1
On Wed, Jul 25, 2018 at 12:16 AM, Michael Shuler
wrote:
> I propose the following artifacts for release as 3.11.3.
>
> sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.3-tentative
> Artifacts:
> https
+1
On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler
wrote:
> I propose the following artifacts for release as 2.2.13.
>
> sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/2.2.13-tentative
> Artifacts:
> https
Bay area event is interesting to me, in any format.
On Thu, Jul 26, 2018 at 9:03 PM, Ben Bromhead wrote:
> It sounds like there may be an appetite for something, but the NGCC in its
> current format is likely to not be that useful?
>
> Is a bay area event focused on C* developers something that
On Mon, Aug 20, 2018 at 4:14 PM Roopa Tangirala
wrote:
> contributions should be evaluated based on the merit of code and their
> value add to the whole offering. I hope it does not matter whether that
> contribution comes from PMC member or a person who is not a committer.
I hope this goes wi
+1 for separate repo
--
Jeff Jirsa
> On Aug 23, 2018, at 1:00 PM, sankalp kohli wrote:
>
> Separate repo is in a majority so far. Please reply to this thread with
> your responses.
>
> On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh
> wrote:
>
>> +1 for se
Can you get all of the contributors cleared?
What’s the architecture? Is it centralized? Is there a sidecar?
> On Aug 27, 2018, at 5:36 PM, Jonathan Haddad wrote:
>
> Hey folks,
>
> Mick brought this up in the sidecar thread, but I wanted to have a clear /
> separate discussion about what we'r
with the ability to
meet the goals of the original proposal (and then some). The reaper UI is nice,
I wish you’d have talked to the other group of folks to combine efforts in
April, we’d be much further ahead.
--
Jeff Jirsa
> On Aug 27, 2018, at 6:02 PM, Jeff Jirsa wrote:
>
> Can yo
+1 from me on both points below
--
Jeff Jirsa
> On Aug 28, 2018, at 1:40 PM, Sumanth Pasupuleti
> wrote:
>
> Correct me if I am wrong, but I see the following consensus so far, on the
> proposal.
>
> C* 2.2
> AnimalSniffer
> Use AnimalSniffer for compi
Agreed here - combining effort and making things pluggable seems like a good
solution
--
Jeff Jirsa
On Aug 28, 2018, at 11:44 PM, Vinay Chella wrote:
>> 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
Read heavy workload with wider partitions (like 1-2gb) and disable the key
cache will be worst case for GC
--
Jeff Jirsa
> On Aug 31, 2018, at 10:51 AM, Carl Mueller
> wrote:
>
> I'm assuming that p99 that Rocksandra tries to target is caused by GC
> pauses, d
Seems like a reasonable thing to merge to me. Nothing else has been
committed, it was approved pre-freeze, seems like the rush to merge was
bound to have some number of rebase casualties.
On Tue, Sep 4, 2018 at 11:15 AM Sam Tunnicliffe wrote:
> Hey all,
>
> On 2018-31-08 CASSANDRA-14145 had been
How can we continue moving this forward?
Mick/Jon/TLP folks, is there a path here where we commit the
Netflix-provided management process, and you augment Reaper to work with it?
Is there a way we can make a larger umbrella that's modular that can
support either/both?
Does anyone believe there's a
, starting with
something small 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 (a
what was proposed.
--
Jeff Jirsa
> On Sep 7, 2018, at 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 proce
+1 as well.
On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko
wrote:
> If this is about inclusion in 4.0, then I support it.
>
> Technically this is *mostly* just a move+donation of some code from
> java-driver to Cassandra. Given how important this seemingly is to the
> board and PMC for us to
+1
(Incubation looks like it may be challenging to get acceptance from all
existing contributors, though)
--
Jeff Jirsa
> On Sep 12, 2018, at 8:12 AM, Nate McCall wrote:
>
> This will be the same process used for dtest. We will need to walk
> this through the incubator per
d - good with either option, but would probably slightly prefer b, as it
can be build towards the design doc.
On Wed, Sep 12, 2018 at 8:19 AM sankalp kohli
wrote:
> Hi,
> Community has been discussing about Apache Cassandra Management process
> since April and we had lot of discussion abou
On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne
wrote:
> That's probably a stupid question, and excuse me if it is, but what does
> those votes on the dev mailing list even mean?
>
> How do you count votes at the end? Just by counting all votes cast,
> irregardless of whomever cast it? Or are w
Also agree it should be lowered, but definitely not to 1, and probably
something closer to 32 than 4.
--
Jeff Jirsa
> On Sep 21, 2018, at 8:24 PM, Jeremy Hanna wrote:
>
> I agree that it should be lowered. What I’ve seen debated a bit in the past
> is the number but I don’t
In some installations, it's used for hashing the partition key to find the
host ( RandomPartitioner )
It's used for prepared statement IDs
It's used for hashing the data for reads to know if the data matches on all
different replicas.
We don't use CRC because conflicts would be really bad. There's
I think 16k is a better default, but it should only affect new tables. Whoever
changes it, please make sure you think about the upgrade path.
> On Oct 12, 2018, at 2:31 AM, Ben Bromhead wrote:
>
> This is something that's bugged me for ages, tbh the performance gain for
> most use cases fa
> On Oct 12, 2018, at 6:46 AM, Pavel Yaskevich wrote:
>
>> On Thu, Oct 11, 2018 at 4:31 PM Ben Bromhead wrote:
>>
>> This is something that's bugged me for ages, tbh the performance gain for
>> most use cases far outweighs the increase in memory usage and I would even
>> be in favor of chan
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 wrote:
>
> We have had PropertyFileSnitch for a long time even though
> GossipingPropertyFileSnitch is e
I can’t think of a situation where I’d choose Cassandra as a database in a
single-host use case (if you’re sure it’ll never be more than one machine).
--
Jeff Jirsa
> On Oct 18, 2018, at 12:31 PM, Abdelkrim Fitouri wrote:
>
> Hello,
>
> I am wondering if using cassand
The write sampling is adding an extra instance with the same schema to test
things like yaml params or compaction without impacting reads or correctness -
it’s different than what you describe
--
Jeff Jirsa
> On Oct 18, 2018, at 5:57 PM, Carl Mueller
> wrote:
>
> I guess t
are often app
specific
--
Jeff Jirsa
> On Oct 18, 2018, at 6:47 PM, Jonathan Ellis wrote:
>
> Isn't this what CDC was designed for?
>
> https://issues.apache.org/jira/browse/CASSANDRA-8844
>
> On Thu, Oct 18, 2018 at 10:54 AM Carl Mueller
> wrote:
>
>&
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
On Mon, Oct 22, 2018 at 7:09 PM J. D. Jordan
wrote:
> Do you have a specific gossip bug that you have seen recently which caused
> a problem that would make this happen? Do you have a specific JIRA in mind?
Sankalp linked a few others, but also
https://issues.apache.org/jira/browse/CASSANDRA-1
My objection (-0.5) is based on freeze not in code complexity
--
Jeff Jirsa
> On Oct 23, 2018, at 8:59 AM, Benedict Elliott Smith
> wrote:
>
> To discuss the concerns about the patch for a more efficient representation:
>
> The risk from such a patch is very low. It’
ct 22, 2018 at 12:52 PM Paulo Motta <
> >>>>> pauloricard...@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>> the new host won’t learn about the host whose status is
> missin
The assignment is just so you get “credit” for the patch - asking for a
reviewer is good but not strictly necessary.
(Some of the committers will try to review it when we can, usually waiting for
someone who’s comfortable with that code to come along)
--
Jeff Jirsa
> On Nov 16, 2018, at
Are you sure you’re blocked on internode and not commitlog? Batch is typically
not what people expect (group commitlog in 4.0 is probably closer to what you
think batch does).
--
Jeff Jirsa
> On Nov 27, 2018, at 10:55 PM, Yuji Ito wrote:
>
> Hi,
>
> Thank you for th
+1
--
Jeff Jirsa
> On Dec 17, 2018, at 7:19 AM, Benedict Elliott Smith
> wrote:
>
> I propose these changes
> <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>*
> to the Jira Workflow for the project. The vote will be open for 7
Definitely worth a JIRA. Suspect it may be slow to get a response this
close to the holidays, but a JIRA will be a bit more durable than the
mailing list post.
On Wed, Dec 19, 2018 at 1:58 PM Sam Klock wrote:
> Cassandra devs,
>
> I have a question about the implementation of
> PartitionUpdate.
+1
--
Jeff Jirsa
> On Jan 4, 2019, at 2: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
>
> Ther
I dont think it's awkward, I think a lot of us know there are serious bugs
and we need a release, but we keep finding other bugs and it's super
tempting to say "one more fix"
We should probably just cut next 3.0.x and 3.11.x though, because there are
some nasty bugs hiding in there that the testin
When we say disable, do you mean disable creation of new SASI indices, or
disable using existing ones? I assume it's just creation of new?
On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña
wrote:
> Hello all,
>
> It is my understanding that SASI is still to be considered an
> experimental/beta
+1 on config
-0 on warning
-0 on disabling by default
--
Jeff Jirsa
> On Jan 14, 2019, at 9:22 PM, Taylor Cressy wrote:
>
> +1 on config. +1 on disabling.
>
> +1 on applying it to materialized views as well.
>
>> On Jan 14, 2019, at 17:29, Joshua McKenzie wr
1 - 100 of 472 matches
Mail list logo
