[
https://issues.apache.org/jira/browse/KAFKA-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias J. Sax resolved KAFKA-7363.
Resolution: Invalid
Please ask question on the mailing list. We use Jira to track bugs only
+1 (binding)
On 9/1/18 2:40 PM, Guozhang Wang wrote:
> +1 (binding).
>
> On Mon, Aug 27, 2018 at 5:20 PM, Dongjin Lee wrote:
>
>> +1 (non-binding)
>>
>> On Tue, Aug 28, 2018 at 8:53 AM Bill Bejeck wrote:
>>
>>> +1
>>>
>>> -Bill
>>>
>>> On Mon, Aug 27, 2018 at 3:24 PM Ted Yu wrote:
>>>
+1
Why do we not deprecate the class? Seems like a breaking change to me --
at least technically. Are we 100% sure that nobody is using it and we
don't break someone's application (I don't think we can ever be 100% sure).
I would prefer to deprecate the class and make it private (ie, remove
from publ
+1 (binding)
On 8/30/18 11:30 PM, Dongjin Lee wrote:
> Thanks for the KIP. I'm +1 (non-binding).
>
> Best,
> Dongjin
>
> On Fri, Aug 31, 2018 at 9:25 AM Dong Lin wrote:
>
>> Thanks for the KIP!
>>
>> +1 (binding)
>>
>> On Thu, Aug 30, 2018 at 3:56 PM, Jason Gustafson
>> wrote:
>>
>>> Hi All,
Thanks for all your comments and taking it easy on me for my first KIP :)
I am trying to check if it's okay for us to start a vote on this? As per
some recent comment I'll change the name to RoundRobinPartitioner.
I'll need to put some effort in writing Scala tests etc. since I'm a novice
with S
Thanks for the KIP,
+1 (non-binding)
On Sun, Sep 2, 2018 at 7:59 PM, Matthias J. Sax
wrote:
> +1 (binding)
>
> On 8/30/18 11:30 PM, Dongjin Lee wrote:
> > Thanks for the KIP. I'm +1 (non-binding).
> >
> > Best,
> > Dongjin
> >
> > On Fri, Aug 31, 2018 at 9:25 AM Dong Lin wrote:
> >
> >> Thanks
Hi,
I've seen Dong has done some work on
https://issues.apache.org/jira/browse/KAFKA-7278 which is said from the
comments that it could have possibly fixed
https://issues.apache.org/jira/browse/KAFKA-1194.
I tested and it is unfortunately not the case...
I have posted in KAFKA-1194 a way to repro
Hi Guozhang,
Yes, you are right. I didn't notice T build() is bounded to .
I was originally thinking T could be an AbstractedRequest or List<>
but I was wrong. Now the return type has to change from T build() to
List build
where . As you mentioned,
this required a change for all the requests, prob
Hi Stephane,
Does https://github.com/apache/kafka/pull/4947/files fix it for you?
Ismael
On Sun, Sep 2, 2018 at 11:25 AM Stephane Maarek <
steph...@simplemachines.com.au> wrote:
> Hi,
>
> I've seen Dong has done some work on
> https://issues.apache.org/jira/browse/KAFKA-7278 which is said from
+1 (non-binding) from me on the interface. I'd like to see someone familiar
with
the code comment on the approach, and note there's a couple of different
approaches: what's documented in the KIP, and what Xiaohe Dong was working
on
here:
https://github.com/dongxiaohe/kafka/tree/dongxiaohe/log-clean
Andy Bryant created KAFKA-7373:
--
Summary: GetOffsetShell doesn't work when SSL authentication is
enabled
Key: KAFKA-7373
URL: https://issues.apache.org/jira/browse/KAFKA-7373
Project: Kafka
Iss
Hi Yishun,
I was actually not suggesting we should immediately make such dramatic
change on the AbstractRequest APIs which will affect all requests types,
just clarifying if it is your intent or not, since your code snippet in the
KIP has "@Override" :)
I think an alternative way is to add such
Hi Ismael, thanks for having a look!
https://github.com/apache/kafka/pull/4947/files does not fix it for me.
But this one does: https://github.com/apache/kafka/pull/4431
It produces the following log: https://pastebin.com/NHeAcc6v
As you can see the folders do get renamed, it gives the user a few
13 matches
Mail list logo
