Thanks Sophie, I think for KIP-441 the streams client would not need to
rely on the returned boolean flag so I was a bit confused before. Now I
understand it is for other use cases where users do not (or cannot) rely on
the returned assignment to decide if a rebalance is still requested so
checking
Ok, I think I see what you're getting at.
No, we obviously would only want to trigger one additional rebalance after
the current one completes since the next rebalance would of course have
the metadata updates we want. But if enforceRebalance returns false a
second time, we don't know whether it w
Hi Sophie,
So just to clarify, with the updated API we would keep calling
enforceRebalance until it returns true for cases where we rely on it with
new subscription metadata?
Guozhang
On Wed, Feb 12, 2020 at 5:14 PM Sophie Blee-Goldman
wrote:
> Thanks Boyang -- makes sense to me. I've optimist
Thanks Boyang -- makes sense to me. I've optimistically updated the KIP
with this new signature and behavior.
On Wed, Feb 12, 2020 at 4:27 PM Boyang Chen
wrote:
> Hey Sophie,
>
> I'm satisfied with making enforceRebalance() not throwing any exception
> other than illegal state. You could imagin
Hey Sophie,
I'm satisfied with making enforceRebalance() not throwing any exception
other than illegal state. You could imagine this KIP is just making the
`rejoinNeededOrPending` external to user requests. Make it as lightweight
as possible makes sense.
Boyang
On Wed, Feb 12, 2020 at 2:14 PM So
Hey Guozhang, thanks for the thorough reply!
I definitely went back and forth on whether to make it a blocking call,
and ultimately went with blocking just to leave it open to potential future
use cases (in particular non-Streams apps). But on second (or third)
thought I think I agree that no use
Hello Sophie, thanks for brining up this KIP, and the great write-up
summarizing the motivations of the proposal. Here are some comments:
Minor:
1. If we want to make it a blocking call (I have some thoughts about this
below :), to be consistent we need to consider having two overloaded
function,
Hey Boyang,
Originally I had it as a nonblocking call, but decided to change it to
blocking
with a timeout parameter. I'm not sure a future makes sense to return here,
because the rebalance either does or does not complete within the timeout:
if it does not, you will have to call poll again to com
Hey Sophie,
is the `enforceRebalance` a blocking call? Could we add a code sample to
the KIP on how this API should be used?
Returning a future instead of a boolean might be easier as we are allowing
consumer to make progress during rebalance after 429 IMHO.
Boyang
On Tue, Feb 11, 2020 at 1:17
Thanks for the quick turnaround Sophie. My points have been addressed.
I think the intended use is quite clear now.
Best,
Konstantine
On Tue, Feb 11, 2020 at 12:57 PM Sophie Blee-Goldman
wrote:
> Konstantine,
> Thanks for the feedback! I've updated the sections with your suggestions. I
> agree
Konstantine,
Thanks for the feedback! I've updated the sections with your suggestions. I
agree
in particular that it's really important to make sure users don't call this
unnecessarily,
or for the wrong reasons: to that end I also extended the javadocs to
specify that this
API is for when changes
Hi Sophie,
Thanks for the KIP, makes sense to me.
One quick question, I'm not sure if it's relevant or not.
If a user provides a `ConsumerRebalanceListener` and a rebalance is
triggered from an `enforceRebalance` call,
it seems possible the listener won't get called since partition assignments
Hi Sophie.
Thanks for the KIP. I liked how focused the proposal is. Also, its
motivation is clear after carefully reading the KIP and its references.
Yet, I think it'd be a good idea to call out explicitly on the Rejected
Alternatives section that an automatic and periodic triggering of
rebalance
Sounds perfect. Thanks!
-John
On Mon, Feb 10, 2020, at 19:18, Sophie Blee-Goldman wrote:
> Thanks John. I took out the KafkaConsumer method and moved the javadocs
> to the Consumer#enforceRebalance in the KIP -- hope you're happy :P
>
> Also, I wanted to point out one minor change to the current
Thanks John. I took out the KafkaConsumer method and moved the javadocs
to the Consumer#enforceRebalance in the KIP -- hope you're happy :P
Also, I wanted to point out one minor change to the current proposal: make
this
a blocking call, which accepts a timeout and returns whether the rebalance
com
Thanks Sophie,
Sorry I didn't respond. I think your new method name sounds good.
Regarding the interface vs implementation, I agree it's confusing. It's
always bothered me that the interface redirects you to an implementation
JavaDocs, but never enough for me to stop what I'm doing to fix it.
It'
Since this doesn't seem too controversial, I'll probably call for a vote by
end of day.
If there any further comments/questions/concerns, please let me know!
Thanks,
Sophie
On Sat, Feb 8, 2020 at 12:19 AM Sophie Blee-Goldman
wrote:
> Thanks for the feedback! That's a good point about trying to
Thanks for the feedback! That's a good point about trying to prevent users
from
thinking they should use this API during normal processing and clarifying
when/why
you might need it -- regardless of the method name, we should explicitly
call this out
in the javadocs.
As for the method name, on refl
Hi all,
Thanks for the well motivated KIP, Sophie. I had some alternatives in mind,
which
I won't even bother to relate because I feel like the motivation made a
compelling
argument for the API as proposed.
One very minor point you might as well fix is that the API change is targeted at
KafkaCo
This situation was discussed at length after a recent talk I gave. This KIP
would be a great step towards increased availability and in facilitating
lightweight rebalances.
anna
On Fri, Feb 7, 2020, 9:38 PM Sophie Blee-Goldman
wrote:
> Hi all,
>
> In light of some recent and upcoming rebalanc
Hi all,
In light of some recent and upcoming rebalancing and availability
improvements, it seems we have a need for explicitly triggering a consumer
group rebalance. Therefore I'd like to propose adding a new rejoinGroup()method
to the Consumer client (better method name suggestions are very welco
21 matches
Mail list logo
