With 8 binding +1, 1 non-binding +1, and no other votes, the 3.0.15 vote
has passed. I'll get the artifacts published soon.
--
Kind regards,
Michael
On 10/02/2017 12:18 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.0.15.
>
> sha1:
As long as balanced is achieved, fewer vnodes the better
--
Jeff Jirsa
> On Oct 9, 2017, at 7:53 AM, Li, Guangxing wrote:
>
> Jeff,
>
> so the key really is to keep nodes load balanced, and as long as that such
> balance is achieved, using a smaller amount of
On 10/09/2017 10:15 AM, Michael Shuler wrote:
> I count 7 binding +1 votes and no other votes for the 3.11.1 release.
> Thanks for all the feedback. I will publish the release artifacts shortly.
>
Resend with subject updated to [VOTE PASSED] :)
--
Michael
I count 7 binding +1 votes and no other votes for the 3.11.1 release.
Thanks for all the feedback. I will publish the release artifacts shortly.
--
Kind regards,
Michael
On 10/02/2017 12:58 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.11.1.
>
> sha1:
256 was chosen because the original vnode allocation algorithm was random and
fewer than 256 could lead to unbalanced nodes
In 3.0 there’s a less naive algorithm to ensure more balanced distribution, and
there 16 or 32 is probably preferable
--
Jeff Jirsa
> On Oct 9, 2017, at 7:38 AM, Li,
Jeff,
so the key really is to keep nodes load balanced, and as long as that such
balance is achieved, using a smaller amount of vnodes does not have other
negative impact?
Thanks.
George
On Mon, Oct 9, 2017 at 8:46 AM, Jeff Jirsa wrote:
> 256 was chosen because the original
That is good info. Thanks.
George
On Mon, Oct 9, 2017 at 10:23 AM, Jeff Jirsa wrote:
> One of my very smart coworkers who rarely posts to the list pointed out
> privately that I've oversimplified this, and there are other advantages to
> having more vnodes SOMETIMES.
>
> In
One of my very smart coworkers who rarely posts to the list pointed out
privately that I've oversimplified this, and there are other advantages to
having more vnodes SOMETIMES.
In particular: most of our longest streaming operations
(bootstrap/decommission/removenode) are cpu bound on the stream
Varun,
Please open a JIRA ticket with all the details of what you are seeing.
Thanks,
-Jason
On Mon, Oct 9, 2017 at 7:54 PM, Varun Barala
wrote:
> Hi developers,
>
> Recently, I was removing one node from the cluster without downtime.
>
> Cluster size :: 3 node [test