I'm also not convinced the problems listed in the paper with removenode are
so serious. With lots of vnodes per node, removenode causes data to be
streamed into all other nodes in parallel, so is (n-1) times quicker than
replacement for n nodes. For R=3, the failure rate goes up with vnodes
(withou
+1 Although lots of people are still using thrift, it's not a good use of
time to maintain two interfaces when one is clearly better. But, yes,
retaining thrift for some time is important.
On 11 March 2014 17:27, sankalp kohli wrote:
> RIP Thrift :)
> +1 with "We will retain it for backwards co
+1 (non-binding) on getting 2.0.7 out soon
On 16 April 2014 07:44, Sylvain Lebresne wrote:
> On Mon, Apr 14, 2014 at 8:32 PM, Pavel Yaskevich
> wrote:
>
> > Can I push new release of the thrift-server before we roll 2.0.7?
> >
>
> When the vote email goes, the artifacts are already rolled per-
There's a small mistake in CHANGES.txt - these changes from 1.2 branch were
already in 2.0.7:
* Continue assassinating even if the endpoint vanishes (CASSANDRA-6787)
* Schedule schema pulls on change (CASSANDRA-6971)
* Non-droppable verbs shouldn't be dropped from OTC (CASSANDRA-6980)
* Shutdo
rough its paces. You
can read more at http://www.acunu.com/
Thanks
Richard
--
Richard Low
Acunu | http://www.acunu.com | @acunu
On 20 March 2012 14:50, Rick Branson wrote:
> To support a form of DF, I think some tweaking of the replica placement could
> achieve this effect quite well. We could introduce a variable into replica
> placement, which I'm going to incorrectly call DF for the purposes of
> illustration. The k
On 20 March 2012 14:55, Jonathan Ellis wrote:
> Here's how I see Sam's list:
>
> * Even load balancing when growing and shrinking the cluster
>
> Nice to have, but post-bootstrap load balancing works well in practice
> (and is improved by TRP).
Post-bootstrap load balancing without vnodes necessa
On 22 March 2012 05:48, Zhu Han wrote:
> I second it.
>
> Is there some goals we missed which can not be achieved by assigning
> multiple tokens to a single node?
This is exactly the proposed solution. The discussion is about how to
implement this, and the methods of choosing tokens and replica
