Hi Jun,
I see. Yes, that makes sense. Are we going to do that only for the fetches
whose per partition fetch size cannot reach the first index entry after the
fetch position, or are we going to do that for any fetch? If we do that for
any fetch, then we will still need to read the actual log segme
Sounds good to me.
On Sun, Dec 10, 2017 at 10:14 PM, Ismael Juma wrote:
> Thanks Guozhang.
>
> Cherry-picking also occurred to me sometime after I sent the email and I
> agree that it's useful functionality.
>
> Do I understand correctly that you are suggesting a script for
> cherry-picking afte
On Fri, Dec 8, 2017, at 16:56, Jun Rao wrote:
> Hi, Jiangjie,
>
> What I described is almost the same as yours. The only extra thing is to
> scan the log segment from the identified index entry a bit more to find a
> file position that ends at a message set boundary and is less than the
> partitio
Thanks Guozhang.
Cherry-picking also occurred to me sometime after I sent the email and I
agree that it's useful functionality.
Do I understand correctly that you are suggesting a script for
cherry-picking after the pull request has been merged? We could explore
this, but not sure it would add mu
On Sun, Dec 10, 2017, at 22:10, Colin McCabe wrote:
> On Fri, Dec 8, 2017, at 01:16, Jan Filipiak wrote:
> > Hi,
> >
> > sorry for the late reply, busy times :-/
> >
> > I would ask you one thing maybe. Since the timeout
> > argument seems to be settled I have no further argument
> > form your si
On Fri, Dec 8, 2017, at 01:16, Jan Filipiak wrote:
> Hi,
>
> sorry for the late reply, busy times :-/
>
> I would ask you one thing maybe. Since the timeout
> argument seems to be settled I have no further argument
> form your side except the "i don't want to".
>
> Can you see that connection.ma
[
https://issues.apache.org/jira/browse/KAFKA-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guozhang Wang resolved KAFKA-5318.
--
Resolution: Fixed
> Streams state may be misleading
> ---
>
>
Thanks Ismael for initiating this discussion. I am in favor for adopting
Gitbox for its clean improvements since many of us have shared the pain of
managing PRs for long time.
About this potential downsides, subjectively I feel these two arguments are
quite handle-able. The only concern I had abou
The by-laws ask for 72 hours only, since the starting of the vote, and
since you have three binding votes you can close this voting now.
Please conclude by a summary of the voting status including non-binding and
binding votes, thanks.
Guozhang
On Sun, Dec 10, 2017 at 8:10 PM, Hu Xi wrote:
>
Hi all, Would we safely accept this KIP since three binding votes have already
been collected (from Jun, Guozhang and Becket)?
发件人: Guozhang Wang
发送时间: 2017年12月6日 22:40
收件人: dev@kafka.apache.org
主题: Re: [VOTE] KIP-223 - Add per-topic min lead and per-partition
GitHub user scholzj opened a pull request:
https://github.com/apache/kafka/pull/4310
DOCU: Add authorizer.class.name to the security section in documentation
The section _7.4 Authorization and ACLs_ in Kafka documentation describes
how to use ACLs. But it doesn't seem to contain the
Hi Jun,
Thank you!
5. Yes, that makes sense. Agree that we don't want to add protocol changes
to *UpdateMetadataRequest* in this KIP. I have moved the update of
*log.message.format.version* and *inter.broker.protocol.version* to reduce
restarts during upgrade to* Future Work*. We can do this in a
12 matches
Mail list logo
