+1 (non-binding)
On Fri, 31 Jan 2020 at 08:48, Joshua McKenzie wrote:
> +1
>
> On Thu, Jan 30, 2020 at 4:31 PM Brandon Williams wrote:
>
> > +1
> >
> > On Thu, Jan 30, 2020 at 1:47 PM Mick Semb Wever wrote:
> > >
> > > Proposing the test build of Cassandra 4.0-alpha3 for release.
> > >
> > > s
Yes, I'm against it. We should be using the default value that benefits the
most people, rather than an arbitrary compromise.
Most clusters don't shrink, they stay the same size or grow. I'd say 90% or
more fall in this category. Let's do the right thing by default and
include good comments that
Any objections to the compromise of 16 as proposed in Chris's original
patch?
-Joey
On Thu, Jan 30, 2020, 3:47 PM Anthony Grasso
wrote:
> I think lowering the number of tokens is a great idea! Similar to Jon, when
> I have reduced the number of tokens for clients it has been improvement in
> re
I think lowering the number of tokens is a great idea! Similar to Jon, when
I have reduced the number of tokens for clients it has been improvement in
repair performance.
I am concerned that the proposed default value for num_tokens is too low.
If you set up a cluster using the proposed defaults,
+1
On Thu, Jan 30, 2020 at 4:31 PM Brandon Williams wrote:
> +1
>
> On Thu, Jan 30, 2020 at 1:47 PM Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 4.0-alpha3 for release.
> >
> > sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29
> > Git:
> https://gitbox.apache.org/repos/asf?
>From my 4.0 status progress email earlier today, we still have quite a few
testing initiatives that are lacking Shepherds or tracking tickets in JIRA:
[Areas needing Shepherds] - 6
...
[Areas needing tracking tickets] - 11
...
I went ahead and tried out the format of creating an epic in JIRA as
+1
On Thu, Jan 30, 2020 at 1:47 PM Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0-alpha3 for release.
>
> sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha3-tentative
> Maven Artifact
+1
Thanks for getting this started, Mick!
On Fri, Jan 31, 2020 at 8:47 AM Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0-alpha3 for release.
>
> sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/
Proposing the test build of Cassandra 4.0-alpha3 for release.
sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha3-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra
>
> I opened an infra ticket this morning
Well that was quick (it's done). I'll be setting up that test epic today.
On Thu, Jan 30, 2020 at 11:46 AM Joshua McKenzie
wrote:
> Got a 4.0 progress update for everyone:
>
> First off, the 4.0 board can be found at
> https://issues.apache.org/jira/se
Got a 4.0 progress update for everyone:
First off, the 4.0 board can be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355.
The broad view: We have a total of 95 tickets open for 4.0 releases:
https://issues.apache.org/jira/issues/?filter=12347896
One report I often fin
Larger clusters is where high token counts do the most damage. That's why
it's such a problem. You start out with a small cluster using 256, as you
grow into the hundreds it becomes more and more unstable.
On Thu, Jan 30, 2020, 8:19 AM onmstester onmstester
wrote:
> Shouldn't we consider the cl
Shouldn't we consider the cluster size to configure num_tokens?
For example is it OK to use num_tokens=4 for a cluster of more than 100 of
nodes?
Another question that is not so much relevant to this :
When we use the token assignment algorithm (the new/non-random one) for a
specific keyspa
13 matches
Mail list logo