Re: [DISCUSS] KIP-333 Consider a faster form of rebalancing

2019-06-04 Thread Boyang Chen
the state. Boyang From: Matthias J. Sax Sent: Tuesday, June 4, 2019 1:29 PM To: dev Subject: Fwd: [DISCUSS] KIP-333 Consider a faster form of rebalancing Just cycling back to this older KIP discussion. I still have some concerns about the proposal, and there was

Fwd: [DISCUSS] KIP-333 Consider a faster form of rebalancing

2019-06-03 Thread Matthias J. Sax
-333 Consider a faster form of rebalancing Date: Sun, 30 Sep 2018 12:01:14 -0700 From: Matthias J. Sax Organization: Confluent Inc To: dev@kafka.apache.org What is the status of this KIP? I was just catching up and I agree with Becket that it seems a very special use case, that might not be

Re: [DISCUSS] KIP-333 Consider a faster form of rebalancing

2018-09-30 Thread Matthias J. Sax
What is the status of this KIP? I was just catching up and I agree with Becket that it seems a very special use case, that might not be generic enough to be part of Kafka itself. Also, for regular rebalance, as Becket pointed out, catching up should not take very long. Only for longer offline time

Re: [DISCUSS] KIP-333 Consider a faster form of rebalancing

2018-08-07 Thread Becket Qin
Hi Richard, Sorry for the late response. As discussed in the other offline thread, I am still not sure if this use case is common enough to have a built-in rebalance policy. I think usually the time to detect the consumer failure and rebalance would be the longer than the catching up time as the

Re: [DISCUSS] KIP-333 Consider a faster form of rebalancing

2018-07-17 Thread Richard Yu
Hi Becket, I made some changes and clarified the motivation for this KIP. :)It should be easier to understand now since I included a diagram. Thanks,Richard Yu On Tuesday, July 17, 2018, 4:38:11 PM GMT+8, Richard Yu wrote: Hi Becket, Thanks for reviewing this KIP. :) I probably did no

Re: [DISCUSS] KIP-333 Consider a faster form of rebalancing

2018-07-17 Thread Richard Yu
Hi Becket, Thanks for reviewing this KIP. :) I probably did not explicitly state what we were trying to avoid by introducing this mode. As mentioned in the KIP, there is a offset lag which could result after a crash. Our main goal is to avoid this lag (i.e. the latency in terms of time that res

Re: [DISCUSS] KIP-333 Consider a faster form of rebalancing

2018-07-16 Thread Becket Qin
Hi Richard, Thanks for the KIP. I am a little confused on what is proposed. The KIP suggests that after recovery from a consumer crash, there will be two consumers consuming from the same partition. One consumes starting from the log end offset at the point of recovery, and another consumes starti

[DISCUSS] KIP-333 Consider a faster form of rebalancing

2018-07-05 Thread Richard Yu
Hi all, I would like to discuss KIP-333 (which proposes a faster mode of rebalancing). Here is the link for the KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-333%3A+Add+faster+mode+of+rebalancing Thanks, Richard Yu