/CASSANDRA-7622
> >
> > Any insights would be helpful.
> >
> > Thanks!
> > Sagar.
> >
> > On Sat, Mar 2, 2019 at 7:23 AM Jonathan Haddad
> wrote:
> >
> > > Instead of logging to tables, putting a virtual table around the audit
> /
> &
; of Zstd compression levels.
>
> Dinesh
>
> > On Mar 1, 2019, at 6:41 PM, Jonathan Haddad wrote:
> >
> > Hey all,
> >
> > I finally got around to doing some testing. Nothing too crazy, I had it
> > run on my laptop while I did other things around the
Hey all,
I finally got around to doing some testing. Nothing too crazy, I had it
run on my laptop while I did other things around the house.
Test 1: Inserting Random Data in a K/V table, 10 million inserts
LZ4 compression rate: 0.909857609644112
ZStd: 0.6136099401596449
Test 2: Inserting fairl
, side-channel file storage
> > >> format for transient things like this (hints, batches, audit logs,
> etc)
> > >> could be useful as a first class citizen in the codebase? i.e. a world
> > in
> > >> which we refactored some of the hints-specific reader/
Agreed with Dinesh and Josh. I would *never* put the audit log back in
Cassandra.
This is extendable, Sagar, so you're free to do as you want, but I'm very
opposed to putting a ticking time bomb in Cassandra proper.
Jon
On Thu, Feb 28, 2019 at 8:38 AM Dinesh Joshi
wrote:
> I strongly echo Jo
Seems low risk, potentially high reward.
I can run some tests next week to get a rough idea of how compression
ratios differ as well as if there's a difference in performance.
I won't be testing correctness, just looking at the performance profile.
Jon
On Fri, Feb 15, 2019 at 9:56 AM Michael
I think having the discussion around EOL is pretty important, in order to
set the right expectations for the community.
Looking at the commits for 2.1, there's hardly any activity going on,
meaning it's effectively been EOL'ed for a long time now. I think it's
better that we be honest with folks
+1
On Sun, Feb 3, 2019 at 9:35 AM Nate McCall wrote:
> On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler
> wrote:
> >
> > I propose the following artifacts for release as 3.11.4.
> >
> > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.gi
+1
On Sun, Feb 3, 2019 at 9:44 AM Nate McCall wrote:
> On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler
> wrote:
> >
> > I propose the following artifacts for release as 3.0.18.
> >
> > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.gi
In addition to what Jeff mentioned, there was an optimization in 3.4 that
can significantly reduce the number of sstables accessed when a LIMIT
clause was used. This can be a pretty big win with TWCS.
http://thelastpickle.com/blog/2017/03/07/The-limit-clause-in-cassandra-might-not-work-as-you-thi
I'm +1 on the warning for two reasons.
> A cqlsh warning only applies to those that create the sasi via cqlsh.
1. When people are creating their schemas in development, this is usually
the first step. You use the REPL to figure out what you need, then you
copy your schema somewhere else. The wa
Ping on this.
On Mon, Jan 7, 2019 at 5:58 PM Michael Shuler
wrote:
> No problem, thanks for asking :)
>
> Michael
>
> On 1/7/19 6:20 PM, Jonathan Haddad wrote:
> > It's been 5 months and 30+ bug fixes to each branch.
> >
> > Here's the two changelogs:
I'm very much in favor of a warning, and I lean towards disabling them (and
MVs, while we're at it) by default as well.
I've seen both features be the death of clusters, and are a major risk for
teams that are brand new to Cassandra.
On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña
wrote:
>
It's been 5 months and 30+ bug fixes to each branch.
Here's the two changelogs:
https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt
How's everyone feel about getting a release out this week / early next
week? Som
rust
> database. When gpg key signer changes, users need to modify their trust
> on every node, importing new key(s), in order for packages to
> install/upgrade with apt or yum.
>
> I don't understand how adding keys changes release frequency. Did
> someone request a release to
That's a good point. Looking at the ASF docs I had assumed the release
manager was per-project, but on closer inspection it appears to be
per-release. You're right, it does say that it can be any committer.
http://www.apache.org/dev/release-publishing.html#release_manager
We definitely need mor
I agree with Stefan, if someone isn't a release manager there's no reason
to add them, and it just increases the surface area for potential attack or
issue.
On Mon, Jan 7, 2019 at 11:35 AM Stefan Podkowinski wrote:
> I don't see any reason to have any keys in there, except from release
> manager
fter the above cassandra-builds commit.
> - https://builds.apache.org/job/Cassandra-Job-DSL/
>
> The only other consideration I can think of after migration is checking
> the git.a.o bare and github mirror post-commit hooks work as expected.
> - http://git.apache.org/cassandra.git/
>
Silence can be interpreted either as non-awareness or implicit approval.
I interpreted (and meant) +1 as "go for it now".
On Fri, Jan 4, 2019 at 8:48 AM Sam Tunnicliffe wrote:
> Yeah, I wasn’t really proposing a vote as like you said, it’s happening
> anyway. I was just going to give a few days
+1
On Fri, Jan 4, 2019 at 8:13 AM Ariel Weisberg wrote:
> +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 gitb
+1
On Mon, Dec 17, 2018 at 9:50 AM Blake Eggleston
wrote:
> +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 <
> jasedbr...@gmail.com> wrote:
> >
> > +1.
> >
> > On Mon, Dec 17, 2018 at 7:36
My personal preference is to remove labels, but I don't see it as a huge
issue if they stay.
1. A
2. prefer to remove (I suppose I'm a -.1?)
3. +1
4. +1
5. No preference
6. +1
On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID
wrote:
> 1: Component. (A) Multi-select
> 2: Labels: le
they are.
> >
> > --
> > Sylvain
> >
> >
> >> I will make this more explicit for the vote, but just to clarify the
> >> intention so that we are all discussing the same thing.
> >>
> >>
> >>> On 20 Nov 2018, at 14:18, Ariel
If nobody has any objections to CASSANDRA-14303 (default RF) being merged
in I can take care of it. It's a significant usability improvement, looks
well tested and will prevent a number of headaches.
I'll try to get to it tomorrow.
Thanks for bringing these up, Vinay.
Jon
On Tue, Nov 20, 2018
Correct.
On Mon, Nov 19, 2018 at 1:02 PM Steinmaurer, Thomas <
thomas.steinmau...@dynatrace.com> wrote:
> Hello,
>
> am I right that Java 11 support will only be in Cassandra 4.0 and not in
> future releases of the 3.11.x series? Just want to be sure.
>
> Thanks,
> Thomas
>
> The contents of this
Sounds good to me.
On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith
wrote:
> So, this thread somewhat petered out.
>
> There are still a number of unresolved issues, but to make progress I
> wonder if it would first be helpful to have a vote on ensuring we are ANSI
> SQL 92 compliant for o
is point
> >
> > -0:
> > Sylvaine Lebresne
> >
> > -.5:
> > Jeff Jirsa
> >
> > This
> > (
> https://github.com/aweisberg/cassandra/commit/a9ae85daa3ede092b9a1cf84879fb1a9f25b9dce)
>
> > is a rough cut of the change for the representa
d
and we never were really explicit that those sort of optimizations would be
excluded after our feature freeze. I don't think they should necessarily
be excluded at this time, but it depends on the size and risk of the patch.
On Sat, Oct 20, 2018 at 8:38 AM Jonathan Haddad wrote:
> I th
I think we should try to do the right thing for the most people that we
can. The number of folks impacted by 64KB is huge. I've worked on a lot
of clusters created by a lot of different teams, going from brand new to
pretty damn knowledgeable. I can't think of a single time over the last 2
years
Recently I reached an inflection point where my annoyance of launching
clusters finally overcame my laziness. I wanted something similar to CCM,
so I wrote it.
The tool was designed for our usage at TLP, which usually means quickly
firing up clusters for running tests. It started out as some scr
Thanks for bringing this up, it definitely needs to be discussed.
Last surprise is difficult here, since all major databases have their own
way of doing things and people will just assume that their way is the right
way. On that note, some people will be surprised no matter what we do.
I'd rathe
sh Joshi wrote:
> > > Jon, thanks for starting this thread!
> > >
> > > I have created CASSANDRA-14784 to track this.
> > >
> > > Dinesh
> > >
> > >> On Sep 21, 2018, at 9:18 PM, Sankalp Kohli
> > wrote:
> > >>
&g
--
> > 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 think anyone thinks that it should remain
>
One thing that's really, really bothered me for a while is how we default
to 256 tokens still. There's no experienced operator that leaves it as is
at this point, meaning the only people using 256 are the poor folks that
just got started using C*. I've worked with over a hundred clusters in the
l
Sure - I'm not disagreeing with you that pre-built packages would be nice
to have. That said, if someone's gone through the trouble of building an
entire testing infrastructure and has hundreds of machines available,
running `docker-compose up build-deb` is likely not a major issue. If I'm
trying
It seems to me that improving / simplifying the process of building the
packages might solve this problem better. For example, in the tests you
linked to, they were using a custom build that hadn't been rolled into
trunk. I expect we're going to see a lot of that.
If we make building a deb packa
cussion.
>
> From Sylvain
> 2. About the voting process...I think that was addressed by Jeff Jirsa and
> deserves a separate thread as it is not directly related to this thread.
> 3. Does the project need a side car.
>
> From Jonathan Haddad
> 4. Are people doing +1 willin
This voting process feels a bit rushed and frankly not well thought out.
In addition to Sylvain's valid points, which you (Sankalp) didn't address
at all, the discussion in the other threads seemed to be ongoing. The last
email you wrote on one of them was asking for additional feedback, that
indi
I'm +0, and I share the same concerns as Sylvain.
For those of you that have +1'ed, are you planning on contributing to the
driver? Docs, code, QA? It's easy to throw a +1 down to make the driver
the responsibility of the project if you're asking others to do the work.
I vote this way because I
It's interesting to me that someone would consider features of Reaper as
"technical debt"... an odd way to word it. When we had proposed donating
Reaper to the project, I had made the assumption people would realize the
benefit of folding in a successful project. A working codebase with a
large u
We haven’t even defined any requirements for an admin tool. It’s hard to
make a case for anything without agreement on what we’re trying to build.
On Fri, Sep 7, 2018 at 7:17 PM Jeff Jirsa wrote:
> How can we continue moving this forward?
>
> Mick/Jon/TLP folks, is there a path here where we com
Test plans and results could be posted to said
> JIRAs, to be closed once a given test passes. Any bugs found can also then
> be related back to such a ticket for tracking them as well.
>
> -Jeremiah
>
> > On Sep 6, 2018, at 12:27 PM, Jonathan Haddad wrote:
> >
> &g
ers, looks like most testing is done by doing
> an operation or running a load and seeing if it "worked" and no errors in
> logs.
>
> Another important thing will be to fix bugs asap ahead of testing, as
> fixes can lead to more bugs :)
>
> On Thu, Sep 6, 2018 at 7:5
ab9c298e80ad8e76f11a563b4d250c1ae38@%3Cdev.cassandra.apache.org%3E
On Thu, Sep 6, 2018 at 10:35 AM Jordan West wrote:
> Thanks for staring this thread Jon!
>
> On Thu, Sep 6, 2018 at 5:51 AM Jonathan Haddad wrote:
>
> > For 4.0, I'm thinking it would be a good idea to put together a list of
> t
For 4.0, I'm thinking it would be a good idea to put together a list of the
things that need testing and see if people are willing to help test / break
those things. My goal here is to get as much coverage as possible, and let
folks focus on really hammering on specific things rather than just fir
ng this year? We
> may
> > also be able to provide space in bay area and help to organize it.
> (Please
> > let us know, so we could get final approval for that).
> >
> > On Fri, Jul 27, 2018 at 10:05 AM Jonathan Haddad
> > wrote:
> >
> > > My interp
Definitely does not belong in the same repo.
I’m all for folding drivers in / writing our own, just needs active
committers.
On Fri, Aug 31, 2018 at 7:45 AM Michael Shuler
wrote:
> On 08/31/2018 09:34 AM, Jay Zhuang wrote:
> > That's great. Could that be in the same repo as Cassandra or a
> > s
Advertised, yes, but so far I haven't found it to be any better than
ParNew + CMS or G1 in the performance tests I did when writing
http://thelastpickle.com/blog/2018/08/16/java11.html.
That said, I didn't try it with a huge heap (i think it was 16 or 24GB), so
maybe it'll do better if I throw 50
I'm also very interested.
On Tue, Aug 28, 2018 at 8:47 AM Dinesh Joshi
wrote:
> > On Aug 28, 2018, at 6:33 AM, Marcus Olsson
> wrote:
> >
> > Hi,
> >
> > With the risk of stirring the repair/side-car topic even further I'd
> just like to mention that we have recently gotten approval to contri
and we're
finishing up the rework of the code to run it as a sidecar.
On Mon, Aug 27, 2018 at 6:02 PM Jeff Jirsa wrote:
> 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
Hey folks,
Mick brought this up in the sidecar thread, but I wanted to have a clear /
separate discussion about what we're thinking with regard to contributing
Reaper to the C* project. In my mind, starting with Reaper is a great way
of having an admin right now, that we know works well at the ki
Strongly agree with Blake. In my mind supporting multiple versions is
mandatory. As I've stated before, we already do it with Reaper, I'd
consider it a major misstep if we couldn't support multiple with the
project - provided admin tool. It's the same reason dtests are separate -
they work with
Speaking from experience (Reaper), I can say that developing a sidecar
admin / repair tool out of tree that's compatible with multiple versions
really isn't that big of a problem. We've been doing it for a while now.
https://github.com/thelastpickle/cassandra-reaper/blob/master/.travis.yml
On Fr
Pushing it back means it’s a bigger risk later on. I’m +.5 on upgrading now
On Wed, Aug 15, 2018 at 11:46 PM dinesh.jo...@yahoo.com.INVALID
wrote:
> Jason,
> Given that we're so close to the 9/1 date, I would err on the side of
> caution especially given the low value prop. If someone does run i
I fired up trunk to check something, and noticed this:
INFO [Service Thread] 2018-08-08 15:01:36,723 GCInspector.java:290 - G1
Young Generation GC in 339ms. G1 Eden Space: 4634705920 -> 0; G1 Old Gen:
1190138352 -> 1435504616; G1 Survivor Space: 406847488 -> 301989888;
which I thought was a bit
+1 to worklog
On Mon, Aug 6, 2018 at 9:44 AM Ariel Weisberg wrote:
> 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 c
My interpretation of Nate's statement was that since there would be a bunch
of us at Lynn's event, we might as well do NGCC at the same time.
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 likel
+1
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> +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=ca
+1
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> +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=ca
+1
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> +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=ca
+1,
I've come around on this, I think the long and short term benefits
will be worth it.
On Fri, Jul 13, 2018 at 11:17 AM Vinay Chella
wrote:
>
> +1 nb
>
> Regards,
> Vinay Chella
>
>
> On Fri, Jul 13, 2018 at 11:15 AM Michael Shuler
> wrote:
>
> > +0
> >
> > There are pros and cons. I do hope t
>
> Deferring huge amount of commits gives rebase/redo hell. That's the
> biggest impact and the order in which these deferred commits are then
> actually committed can make it more painful or less painful depending on
> the commit. And that in turn will have to then wait for each contributor
> to
e a situation to need it - besides
> discouraging a new contributor who, let’s be honest, was going to have their
> patch languish for a few months while somebody found time to review it
> anyway. At least this way we can give them a decent excuse!
>
>
>
> > On 10 Jul 2018, a
It’s an embodiment of trust that you will follow the community's prevailing
> rules around commit, and that you’re competent to do so.
>
> If the community wants to change those rules you’re trusted to follow, how
> does this modify your right, or the trust emplaced in you?
&
I guess I look at the initial voting in of committers as the process
by which people are trusted to merge things in. This proposed process
revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
picked) wants to merge a new feature into trunk during the freeze, now
they're not allowed?
; > On Jul 9, 2018, at 12:43 PM, sankalp kohli
> > wrote:
> > >
> > > How is this preventing someone from working and collaborating on an
> > Apache
> > > Project? You can still collaborate on making 4.0 more stable.
> > >
> > >
see how we can improve things here. So if you are -1 on this, please help
> us propose something else to get these tests pass?
>
> And thanks for giving your feedback.
>
> On Mon, Jul 9, 2018 at 10:50 AM Jonathan Haddad wrote:
>
> > Not everyone wants to work and collaborat
assing, how will these
> features be used?
>
> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad wrote:
>
> > I don't see how changing the process and banning feature commits is
> > going to be any help to the project. There may be a couple committers
> > who are int
pen.
> > > >>>
> > > >>> This is more of a call to action and announcement of intent than an
> > > >>> attempt to enforce policy; we can and probably will branch off 4.0,
> > > and
> > > >>> keep trunk technically active.
I agree with Josh. I don’t see how changing the convention around trunk
will improve the process, seems like it’ll only introduce a handful of
rollback commits when people forget.
Other than that, it all makes sense to me.
I’ve been working on a workload centric stress tool on and off for a littl
to be following the lead of the OS vendors that people will be deploying
> Cassandra on top of. And those will not be dropping Python 2 at the end of
> the year.
>
> -Jeremiah
>
> > On Jun 1, 2018, at 12:37 PM, Jonathan Haddad wrote:
> >
> > Both can work. I did a
ing to change. I
> think it will be more than 2 years before people begin asking what
> Python 2 was.
>
>
> On 06/01/2018 10:10 AM, Jonathan Haddad wrote:
> > Supporting both as a next step is logical, removing support for 2 in the
> > next year or two seems reas
Supporting both as a next step is logical, removing support for 2 in the
next year or two seems reasonable enough. Gotta rip the band aid off at
some point.
On Fri, Jun 1, 2018 at 2:34 AM Michael Burman wrote:
> Hi,
>
> Deprecating in this context does not mean removing it or it being
> replaced
Personally I don’t mind dropping support for previsous java versions.
On Fri, May 25, 2018 at 6:33 AM J. D. Jordan
wrote:
> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
> wise, and leaves people’s options open.
>
> -Jeremiah
>
> > On May 25, 2018, at 6:31 AM, Robert S
DataStax invested millions of dollars into Cassandra, tens of thousands of
man hours, hosted hundreds of events and has been a major factor in the
success of the project.
ScyllaDB wants us to change the C* protocol in order to improve features in
a competing database which contributes nothing back
>From where I stand it looks like you've got only two options for any
feature that involves updating the protocol:
1. Don't built the feature
2. Built it in Cassanda & scylladb, update the drivers accordingly
I don't think you have a third option, which is built it only in ScyllaDB,
because that
Avi, if this is something that matters to you, you're more than welcome to
submit a patch to both this project and to the different drivers. Getting
the first 2 optimizations into 4.0 would be nice, I'm sure someone would be
happy to work with you on it.
The third, I can't see why we'd need that
It sounds to me (please correct me if I'm wrong) like Jeff is arguing that
releasing 4.0 in 2 months isn't worth the effort of evaluating it, because
it's a big task and there's not enough stuff in 4.0 to make it worthwhile.
If that is the case, I'm not quite sure how increasing the surface area o
There's always more stuff to try to shoehorn in. We've done big releases
with all the things, it never was stable. We tried the opposite end of the
spectrum, release every month, that really wasn't great either. Personally
I'd be OK with stopping new features by the end of this month and aiming
Off the top of my head I can remember clusters with 600 or 700 nodes with
256 tokens.
Not the best situation, but it’s real. 256 has been the default for better
or worse.
On Thu, Apr 5, 2018 at 7:41 PM Joseph Lynch wrote:
> >
> > We see this in larger clusters regularly. Usually folks have just
That’s exactly what I was thinking too.
There’s also nothing preventing features from being merged into trunk after
we create the 4.0 branch, which in my opinion is a better approach than
trying to jam everything in right before the release.
On Thu, Apr 5, 2018 at 12:06 PM Jason Brown wrote:
> M
To be fair, reaper in 2016 only worked with 2.0 and was just sitting
around, more or less.
Since then we've had 401 commits changing tens of thousands of lines of
code, dealing with fault tolerance, repair retries, scalability, etc.
We've had 1 reaper node managing repairs across dozens of cluster
As requested, I'm alerting the ML that I've got the first patch of several
to come. This one only addresses the ColumnFamilyStore class - and only
changes the name. There's follow up tickets to change method and variable
names. As we agreed, I'm doing this incrementally, so please let's keep
tha
time that's
> likely EOL shortly after?
>
> On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad
> wrote:
> > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
> > require it for Cassandra 4. At this point I feel like we should already
> be
&
Java 8 was marked as EOL in the middle of last year, I hope we wouldn't
require it for Cassandra 4. At this point I feel like we should already be
targeting Java 10 at a minimum.
Personally I'd prefer not to tie our releases to any vendor / product /
package's release schedule.
On Fri, Mar 23,
You could use a load balancing policy at the driver level to do what you
want, mixed with the existing consistency levels as Jeff suggested.
On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller
wrote:
> But we COULD have CL2 write (for RF4)
>
> The extension to this idea is multiple backup/secondary rep
There's an incredible amount of work that would need to be done in order to
make any of this happen. Basically a full rewrite of the entire codebase.
Years of effort.
The codebase would have to move to a shared-nothing actor & message based
communication mechanism before any of this is possible.
Hey Micke, very cool you're looking to improve C*'s performance, we would
absolutely benefit from it.
Have you done any other benchmarks beside the micro one to determine the
total effect of these metrics on the system overall? Microbenchmarks are a
great way to tune small sections of code but th
+1
On Mon, Feb 12, 2018 at 9:51 PM mck wrote:
>
>
> > I propose the following artifacts for release as 3.11.2.
>
>
> Thanks Michael for the recut, very much appreciated.
>
> +1
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ca
Do you need to support TTLs? That might be a bit of an issue.
On Sat, Jan 13, 2018 at 12:41 PM Arthur Kushka wrote:
> Hi folks,
>
> Currently, I working on custom CQL operator that should return the max
> timestamp for some partition.
>
> I don't think that scanning of partition for that kind of
The other option, to avoid having two different v5 implementations, is to
bump 4.0’s protocol version to 6.
On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan
wrote:
> My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol
> for tick/tock stuff and known that when a new version cam
After an upgrade I recommend running upgrade sstables no matter what the
version change is. If it's not needed, nothing will happen.
On Fri, Oct 13, 2017 at 4:30 AM Steinmaurer, Thomas <
thomas.steinmau...@dynatrace.com> wrote:
> And extremely useful/important in the field not being a strict requi
I agree with Aleksey on all points here. Adding that we should update the
docs with warnings about the potential issues with correctness.
On Wed, Oct 4, 2017 at 8:25 AM Aleksey Yeshchenko wrote:
> We already have those for UDFs and CDC.
>
> We should have more: for triggers, SASI, and MVs, at lea
+1
On Thu, Sep 28, 2017 at 1:47 PM Nate McCall wrote:
> +1
>
> On Sep 29, 2017 7:41 AM, "Michael Shuler" wrote:
>
> > I propose the following artifacts for release as 2.2.11.
> >
> > sha1: c510e001481637e1f74d9ad176f8dc3ab7ebd1e3
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.gi
+1
On Thu, Sep 28, 2017 at 1:46 PM Nate McCall wrote:
> +1
>
> On Sep 29, 2017 7:12 AM, "Michael Shuler" wrote:
>
> I propose the following artifacts for release as 2.1.19.
>
> sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> sho
The wiki isn't really used anymore. You can submit patches to improve the
docs in tree now. Fee free to tag me as a reviewer and I'll get to it this
week.
On Sat, Sep 16, 2017 at 10:26 AM Vusal Ahmadoglu
wrote:
> Hello,
>
> Could you please give access me to the apache cassandra wiki?
> e-mail:
I think it's a great idea. I'd like to do the same thing with the available
patches but I'm totally ok with doing that separately.
On Thu, Sep 14, 2017 at 4:50 PM Jeff Jirsa wrote:
> There's a number of JIRAs that are old - sometimes very old - that
> represent bugs that either don't exist in mod
Agreed with Jeff & Jason.
On Tue, Jun 13, 2017 at 11:45 AM Jeff Jirsa wrote:
> Looks great to me - especially the venue. Date wise, Tuesday (19th) lets
> people fly in on Monday instead of costing a weekend, so selfishly that
> seems better to me.
>
>
>
> On Mon, Jun 12, 2017 at 1:30 PM, Gary D
It would be a little weird to change the definition of QUORUM, which means
majority, to mean something other than majority for a single use case.
Sounds like you want to introduce a new CL, HALF.
On Thu, Jun 8, 2017 at 7:43 PM Dikang Gu wrote:
> Justin, what I suggest is that for QUORUM consisten
+1.
Are there guidelines for how to set something like this up or is it tribal
knowledge?
On Wed, May 31, 2017 at 3:05 PM Gary Dusbabek wrote:
> +1. I'm happy to help with logistics.
>
> Mid-to-late September is good, but so is October.
>
> Gary.
>
> On Wed, May 31, 2017 at 2:19 PM, Eric Evans
1 - 100 of 167 matches
Mail list logo
