Hi Mickael,
My apologies for the delay. Overall, the KIP looks good to me.
One small suggestion is to update the docstring of the States field in the
request to
clearly state that all groups are returned if omitted or empty. People rely
on the JSON
description so it would be good to provide the i
Thanks Colin,
> I guess I don't feel that strongly about it. However, if we are going to
> rely on inAnyState() / inStates(...) then let's make sure that the latter
> throws an exception when getting an empty list as an argument (since it will
> do something other than the obvious behavior of
On Thu, Feb 13, 2020, at 08:24, Mickael Maison wrote:
> Hi Colin,
>
> > Can you please specify what the result is when a newer client tries to use
> > this on an older broker? Does that result in an
> > UnsupportedVersionException?
> Yes, in case this feature is not supported by the broker,
> Uns
Hi Colin,
> Can you please specify what the result is when a newer client tries to use
> this on an older broker? Does that result in an
> UnsupportedVersionException?
Yes, in case this feature is not supported by the broker,
UnsupportedVersionException should be raised. Your question made me
loo
Hi Michael,
Thank you for the updated KIP. I have few comments/questions:
1. We already have the "--state" option in the command line tool which can
be used
with "--describe" and we will have "--states" which can be used with
"--list". I feel this
is going to be confusing for users. I wonder if w
Hi Mickael,
Can you please specify what the result is when a newer client tries to use this
on an older broker? Does that result in an UnsupportedVersionException?
I would prefer an Optional in the Java API so that “show all groups” can be
EMPTY.
best,
Colin
On Mon, Jan 27, 2020, at 07:53,
Hi David,
Did that answer your questions? or do you have any further feedback?
Thanks
On Thu, Jan 16, 2020 at 4:11 PM Mickael Maison wrote:
>
> Hi David,
>
> Thanks for taking a look.
> 1) Yes, updated
>
> 2) I had not considered that but indeed this would be useful if the
> request contained m
Hi David,
Thanks for taking a look.
1) Yes, updated
2) I had not considered that but indeed this would be useful if the
request contained multiple states and would avoid doing another call.
The ListGroups response already includes the group ProtocolType, so I
guess we could add the State as well.
Hi Michael,
Please, excuse me for my late feedback. I've got a few questions/comments
while reviewing the KIP.
1. I would suggest to clearly state in the documentation of the state field
that omitting it or providing an empty list means "all".
2. Have you considered including the state in the re
Hi all,
If there's no more feedback, I'll open a vote in the next few days.
Thanks
On Fri, Nov 1, 2019 at 4:27 PM Mickael Maison wrote:
>
> Hi Tom,
>
> Thanks for taking a look at the KIP!
> You are right, even if we serialize the field as a String, we should
> use ConsumerGroupState in the AP
Hi Tom,
Thanks for taking a look at the KIP!
You are right, even if we serialize the field as a String, we should
use ConsumerGroupState in the API.
As suggested, I've also updated the API so a list of states is specified.
Regards,
On Tue, Oct 22, 2019 at 10:03 AM Tom Bentley wrote:
>
> Hi Mic
Hi Mickael,
Thanks for the KIP.
The use of String to represent the desired state in the API seems less
typesafe than would be ideal. Is there a reason not to use the existing
ConsumerGroupState enum (even if the state is serialized as a String)?
While you say that the list-of-names result from l
Bump
Now that the rush for 2.4.0 is ending I hope to get some feedback
Thanks
On Mon, Sep 9, 2019 at 5:44 PM Mickael Maison wrote:
>
> Hi,
>
> I have created a KIP to allow listing groups per state:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-518%3A+Allow+listing+consumer+groups+per+
Hi,
I have created a KIP to allow listing groups per state:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-518%3A+Allow+listing+consumer+groups+per+state
Have a look and let me know what you think.
Thank you
14 matches
Mail list logo
