eassignments/$topic/$partition) **via the other mechansim**.
> So
> > if
> > > you're using /admin/reassign_partitions and you change or cancel part
> of
> > it
> > > via /admin/reassign_partitions, that's OK. Likewise if you're using
> > &
ted the KIP
> accordingly. Could you take another look?
>
> Thanks for all the comments.
>
> Dong
>
>
> On Tue, Dec 19, 2017 at 3:09 PM, Jun Rao wrote:
>
> > Hi, Dong,
> >
> > Thanks for the reply.
> >
> > 10. I was actually just thinking the ca
,
the consumer can potentially reset its offset to the last offset in v3,
which is 22. This way, the consumer can re-consume all the republished
messages.
Thanks,
Jun
On Fri, Dec 22, 2017 at 5:04 PM, Jun Rao wrote:
> Hi, Dong,
>
> Thanks for the updated KIP. Still have some questions
Hi, Boyang,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Sun, Dec 24, 2017 at 4:45 PM, Boyang Chen wrote:
> Hey there,
>
> my name is Boyang who is contributing to Kafka Streams. My user ID is
> bchen225242, and this is my registered email. Could I get the permission to
Hi, Prasanna,
Thanks for your interest. Added you to the contributor list.
Jun
On Fri, Dec 29, 2017 at 9:54 PM, Prasanna Subburaj <
prasanna.subbu...@gmail.com> wrote:
> Hi Team,
>
> I am interested in contributing to Apache Kafka, can you please add me to
> the contributors list so that I can
Hi, Mayank,
Thanks for your interest. Added you to the contributor list.
Jun
On Sat, Dec 30, 2017 at 12:19 PM, Mayank Tankhiwale <
mayank.tankhiw...@gmail.com> wrote:
> Hello Team,
>
> I am Mayank. I am interested in contributing to Apache Kafka.
> Could you please add me to the contributors li
Hi, Rajini,
Thank for the KIP. +1. Just a couple of minor comments below.
50. config.secret.*: Could you document how the encryption/decryption of
passwd work? In particular, how do we support changing config.secret?
51. At the topic level, we also have leader.replication.throttled.replicas
and
Hi, Dong,
Thanks for the reply.
To solve the topic recreation issue, we could use either a global metadata
version or a partition level epoch. But either one will be a new concept,
right? To me, the latter seems more natural. It also makes it easier to
detect if a consumer's offset is still valid
Hi, Dong,
Thanks for the KIP. +1
Jun
On Mon, Dec 18, 2017 at 2:03 PM, Dong Lin wrote:
> Hi all,
>
> Since there are no more outstanding comments, I would like to start voting
> thread for KIP-237:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 237%3A+More+Controller+Health+Metrics
Hi, Sean,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Wed, Jan 3, 2018 at 3:29 PM, Sean Policarpio <
sean.policar...@simplemachines.com.au> wrote:
> Hi,
> Can I please get page creation permissions for my ID 'kdrakon' so that I
> can make a KIP?
>
> Cheers
> Sean
>
>
> -
Hi, Collin,
A few more comments on the KIP.
1. About fetch sequence number. My understanding is that the sequence
number is really used to provide better fencing for requests coming from
different TCP sessions for a given client. Suppose a consumer issues a
fetch request and doesn't get a respons
m the end of the log, or consumer can derive the
> leader_epoch from the most recent message received before it sees
> OffsetOutOfRangeException. So I am not sure it is worth adding the
> leader_epoch to consumer API to address the remaining corner case. What do
> you think?
>
> Tha
and your latest suggestion", are you
> referring to solution related to unclean leader election using leader_epoch
> in my previous email?
>
> Thanks,
> Dong
>
> On Thu, Jan 4, 2018 at 1:33 PM, Jun Rao wrote:
>
> > Hi, Dong,
> >
> > Not sure that I fully unders
; > level.
> >> >
> >> > I made a couple of other changes to the KIP:
> >> >
> >> > 1. The config names used for encoding passwords are now prefixed with
> >> > password.encoder.
> >> > Also added key length as a conf
n by offset_epoch. I suppose that we can use the pair of
> (partition_epoch, leader_epoch) as the offset_epoch, right?
>
> Thanks,
> Dong
>
> On Thu, Jan 4, 2018 at 4:02 PM, Jun Rao wrote:
>
> > Hi, Dong,
> >
> > Got it. The api that you proposed works. The
Hi Guys,
I am passing along the following info from EU. If you are interested in the
event, please contact the coordinator. Thanks.
The EU via its EU-FOSSA 2 project have invited a number of communities
including Apache Kafka to consider taking one of their 3 planned Hackathons
this year, to be h
Hi, Yaodong,
Thanks for the KIP. As Stan mentioned earlier, it seems that this is mostly
covered by KIP-248, which was originally proposed by Victor.
Hi, Victor,
Do you still plan to work on KIP-248? It seems that you already got pretty
far on that. If not, would you mind letting Yaodong take ov
Hi, Colin,
Thanks for running the release. Verified the quickstart for 2.12 binary. +1
from me.
Jun
On Fri, Feb 8, 2019 at 12:02 PM Colin McCabe wrote:
> Hi all,
>
> This is the third candidate for release of Apache Kafka 2.1.1. This
> release includes many bug fixes for Apache Kafka 2.1.
>
>
ic class that we would be adding new methods to is
>>>>> > > org.apache.kafka.clients.admin.AdminClient.
>>>>> > >
>>>>> >
>>>>> > I agree. Thanks for pointing this out!
>>>>> >
>>>>
Take a look at the updates and let me know what you
> think:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-392%3A+Allow+consumers+to+fetch+from+closest+replica
> .
>
> Thanks!
> Jason
>
>
>
>
> On Fri, Jan 11, 2019 at 10:49 AM Jun Rao wrote:
>
>
Hi, Noa,
Thanks for the KIP and sorry for the late response.
The KIP itself looks reasonable. My only concern is that it's very specific
to SSL. We have other configurations that also depend on files (e.g. keytab
in Sasl GSSAPI). It would be inconsistent that we only support the
CLASSPATH: syntax
Hi, Jason,
Thanks for the KIP. Just a couple of more comments.
200. I am wondering if we really need the replica.selection.policy config
in the consumer. A slight variant is that we (1) let the consumer always
fetch from the PreferredReplica and (2) provide a default implementation of
ReplicaSele
> well, then do we still need to change the protocol of metadata request to
> add `rack.id`?
>
>
> Guozhang
>
> On Tue, Mar 26, 2019 at 6:23 PM Jun Rao wrote:
>
> > Hi, Jason,
> >
> > Thanks for the KIP. Just a couple of more comments.
> >
> > 2
Hi, Arun,
Thanks for your interest. I just added arao7676 to the contribution list.
Jun
On Fri, Mar 29, 2019 at 3:05 PM Arun Rao wrote:
> Can you please add me to the contributors list? I would like to start
> contributing to Kafka project.
>
> Thank you
> arun
>
> > this or in a separate conversation but I think a separate one could
> > be
> > > > > better because both discussions can be long and keeping them
> > separated
> > > > > would limit the scope and make them more digestible and focused. If
>
Hi, Viktor,
Thanks for the KIP. A couple of comments below.
1. Another potential thing to do reassignment incrementally is to move a
batch of partitions at a time, instead of all partitions. This may lead to
less data replication since by the time the first batch of partitions have
been completel
rack.id at all and affinity can be determined w/o rack.id via TCP
> header,
> >> plus rack.id may not be "future-proof" additional information is needed
> >> as
> >> well, then do we still need to change the protocol of metadata request
> to
> >>
Hi, Rahul,
Those 2 configs are not supported at the broker level right now. This is
being tracked at https://issues.apache.org/jira/browse/KAFKA-7983.
Thanks,
Jun
On Fri, Apr 5, 2019 at 9:17 AM Rahul Agarwal (Flipkart Data Group)
wrote:
> Hi,
>
> We are using Kafka 1.0.2 and wanted to rate li
ally need this feature for our system. This ticket is currently
> unassigned. Can this ticket be assigned to me? I will send a pull request
> for the feature.
>
> Thanks,
> Rahul
>
> On Fri, Apr 5, 2019 at 9:59 PM Jun Rao wrote:
>
> > Hi, Rahul,
> >
> > Those 2
and apply during the process of
> each request.
>
> The advantage of the current KIP is simple and extensible for the future
> release. The alternative is to introduce a new set of quota related APIs in
> the AdminClient, similar to the ACL related. I'm not sure which one people
The voting thread seems to be referring to the wrong KIP number. It should
be KIP-442 instead of KIP-422.
Thanks,
Jun
On Wed, Apr 3, 2019 at 7:03 PM John Roesler wrote:
> Thanks all. The KIP-442 vote has passed with 3 binding votes (Guozhang,
> Bill, and Damian) and one non-binding vote (me) i
Hi, Everyone,
Sriharsh Chintalapan has been active in the Kafka community since he became
a Kafka committer in 2015. I am glad to announce that Harsh is now a member
of Kafka PMC.
Congratulations, Harsh!
Jun
Hi, Aishwarya,
Thanks for the KIP. Looks good to me. Just one minor comment. If a replica
is deleted on a broker (through a StopReplicaRequest) while it's in the
failed partition set, should we exclude that partition from the set and
the FailedPartitionsCount?
Jun
On Mon, May 6, 2019 at 1:21 PM
Hi, Aishwarya,
Thanks for the KIP. +1
Jun
On Wed, May 8, 2019 at 4:30 PM Aishwarya Gune
wrote:
> Hi All!
>
> I would like to call for a vote on KIP-461 that would improve the behavior
> of replica fetcher in case of partition failure. The fetcher thread would
> just stop monitoring the crashed
Hi, Balazs,
Thanks for your interest. Just added you to the contributor list.
Jun
On Tue, Jun 4, 2019 at 5:56 PM Balazs Bence Sari
wrote:
> Dear Kafka Team,
>
> please register me as a contributor to the Kafka project.
>
> My github id: benyoka
> My JIRA id: bsari
>
> Br
> Bence
> *Balázs Benc
Hi, Guozhang,
Thanks for the KIP. A few comments below.
1. "If the error_records is not empty and the error code is not API
exception and is not retriable, still retry by creating a new batch ".
InvalidTimestampException
is an ApiException. It seems we should still retry the non-error records in
Hi, Garvit,
Thanks for your interest. Added you to the contributor list.
Jun
On Wed, Jun 19, 2019 at 10:18 AM Garvit Sharma wrote:
> Hi,
>
> I would like to contribute to Apache Kafka, Could you please give me
> contributor permission?
> JIRA ID: garvitlnmiit
> Github ID: garvitlnmiit
> Github
Hi, Justine,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Mon, Jun 24, 2019 at 12:19 PM Justine Olshan
wrote:
> Hi, I was wondering if I could have permission to create a KIP. My wiki
> username is jolshan.
>
> Thank you,
> Justine Olshan
>
Hi, Maulin,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Thu, Jun 27, 2019 at 7:16 PM Maulin Vasavada
wrote:
> Hi
>
> Can you please give me permission to Create KIP?
>
> My username: maulin.vasavada
>
> Thank you.
> Maulin
>
Hi, Jose,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Thu, Jul 11, 2019 at 3:39 PM Jose M wrote:
> Hello,
>
> Id like permisssions to create a new KIP on the wiki.
>
> Wiki Id: jose.moralesaragon
>
>
> Thanks a lot,
>
> Jose M
>
Hi, Justine,
Thanks for the KIP. Nice writeup and great results. Just one comment.
100. To add a record to the accumulator, the producer needs to know the
partition id. The decision of whether the record can be added to the
current batch is only made after the accumulator.append() call. So, when
Hi, Ankit,
Thanks for your interest. Just added you to the contributor list.
Jun
On Fri, Jul 12, 2019 at 8:23 AM Ankit Choudhary
wrote:
> Hey Team,
>
> This is Ankit. I work as a Customer Operations Engineer in Cloudera,
> extensively working with Kafka and other related components. And I woul
ays used, or that it will be used on keys is more descriptive. Calling
> it "RoundRobin" seems a bit misleading to me.
>
> Thanks again for reviewing,
> Justine
>
> On Thu, Jul 11, 2019 at 6:07 PM Jun Rao wrote:
>
> > Hi, Justine,
> >
> > Thanks for t
Hi, Justine,
Thanks for the KIP. It looks good overall. Just a followup comment.
Should we mark Partitioner.partition() as deprecated? If someone tries to
implement a new Partitioner on the new interface. They will see both
partition() and computePartition(). It's not clear to them which one they
and instead create a separate
> > method to perform the necessary actions on new batches. I will try to
> > update the KIP with the details as soon as I can.
> >
> > Thank you,
> > Justine
> >
> > On Fri, Jul 26, 2019 at 9:28 AM Jun Rao wrote:
&g
Hi, Guozhang,
Thanks for the KIP. +1
Jun
On Fri, Jul 26, 2019 at 4:40 PM Jason Gustafson wrote:
> Hi Guozhang,
>
> I agree it is misleading to suggest corruption in these cases. Have you
> considered alternative error codes? I think INVALID_REQUEST may be more
> suggestive that the server has
Hi, Jason,
Thanks for the KIP. Looks good overall. A couple of comments below.
10. It's not very clear to me when the partition state (i.e., leader, isr,
leaderEpoch and zkVersion) is updated on the leader. My initial
understanding is that the leader updates the partition state on receiving a
suc
Hi, Colin,
Thanks for the KIP. Sorry for the late reply. LGTM overall. A few detailed
comments below.
10. The KIP adds two new fields (AddingReplicas and RemovingReplicas) to
LeaderAndIsr request. Could you explain how these 2 fields will be used?
Should we include those two fields in UpdateMetad
e5e362255d11be1R521
> .
>
> 13. I think so. (
> https://github.com/apache/kafka/pull/7128#discussion_r308866206). I'll
> reflect this in the KIP
>
> Here is the updated KIP diff -
>
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=112820260&
. Upgrade will be
controlled by inter broker protocol.
Thanks,
Jun
On Wed, Jul 31, 2019 at 1:22 PM Colin McCabe wrote:
> Hi Jun,
>
> Thanks for taking another look at this.
>
> On Wed, Jul 31, 2019, at 09:22, Jun Rao wrote:
> > Hi, Stan,
> >
> > Thanks for the
controller to deal with the new ZK fields. Dealing with the additional
ZK node version bump seems a small thing on top of that?
Thanks,
Jun
On Thu, Aug 1, 2019 at 3:05 PM Colin McCabe wrote:
> On Thu, Aug 1, 2019, at 12:00, Jun Rao wrote:
> > Hi, Colin,
> >
> > 10. Sounds
Hi, Justine,
Thanks for the KIP. Overall, it seems to be a good improvement.
However, I think Harsha's point seems reasonable. We had
auto.create.topics.enable config on the broker to allow admins to disable
topic creation from the producer/consumer clients before we had the
security feature. The
Just a few comments on this.
1. One of the issues with using RAID 0 is that a single disk failure causes
a hard failure of the broker. Hard failure increases the unavailability
window for all the partitions on the failed broker, which includes the
failure detection time (tied to ZK session timeout
Hi, Ismael,
Thanks for running the release. +1. Verified quickstart on the 2.11 binary.
Jun
On Mon, Jun 26, 2017 at 3:53 PM, Ismael Juma wrote:
> Hi Vahid,
>
> There are a few known issues when running Kafka on Windows. A PR with some
> fixes is: https://github.com/apache/kafka/pull/3283. The
Powers, Davor Poldrugo, dejan2609,
> Dhwani Katagade, Dong Lin, Dustin Cote, Edoardo Comar, Eno Thereska, Ewen
> Cheslack-Postava, gosubpl, Grant Henke, Guozhang Wang, Gwen Shapira,
> Hamidreza Afzali, Hao Chen, hejiefang, Hojjat Jafarpour, huxi, Ismael Juma,
> Ivan A. Melnikov, Jai
Hi, Peter,
Thanks for your interest. Just added you to the contributor list.
Jun
On Fri, Jun 30, 2017 at 5:08 AM, Peter Toth wrote:
> Hi,
>
> Could you please add me to the kafka contributors list? My user name is:
> ptoth
>
> Thanks,
> Peter
>
Hi, Everyone,
Ismael Juma has been active in the Kafka community since he became
a Kafka committer about a year ago. I am glad to announce that Ismael is
now a member of Kafka PMC.
Congratulations, Ismael!
Jun
Hi, Mitch,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Thu, Jul 6, 2017 at 10:43 AM, Mitch Seymour
wrote:
> Hello,
>
> I'd like to make some contributions to the wiki. Could someone please grant
> write permissions to the following user?
>
> Username: mitch-seymour
>
>
Congratulations, Jason!
Jun
On Tue, Jul 11, 2017 at 10:32 PM, Guozhang Wang wrote:
> Hi Everyone,
>
> Jason Gustafson has been very active in contributing to the Kafka community
> since he became a Kafka committer last September and has done lots of
> significant work including the most recent
Hi, Dong,
I think Tom was suggesting to have the AlterTopicsRequest sent to any
broker, which just writes the reassignment json to ZK. The controller will
pick up the reassignment and act on it as usual. This should work, right?
Having a separate AlterTopicsRequest and AlterReplicaDirRequest seem
Hi, Tom,
Thanks for the KIP. A few minor comments below.
1. Implementation wise, the broker handles adding partitions differently
from changing replica assignment. For the former, we directly update the
topic path in ZK with the new partitions. For the latter, we write the new
partition reassignm
sult to user. I think if the slight difference in the accuracy between
> the two approaches does not make a difference to the intended use-case of
> this API, then we probably want to re-use the exiting request/response to
> keep the protocol simple.
>
> Thanks,
> Dong
>
>
>
> appended to the partition after the last FetchRequest from the follower.
> > Does this make sense?
> >
> > Thanks,
> > Dong
> >
> >
> >
> > On Wed, Aug 9, 2017 at 4:24 PM, Jun Rao wrote:
> >
> >> Hi, Dong,
> >>
> >>
t always be negative for leader and
> >> in-sync replicas. Note that we can not calculate lag as max(0, HW - LEO)
> >> because we still need the difference between two lags to measure the
> >> progress of intra-broker replica movement. The AdminClient API can
> choose
>
Hi, Sumant,
Thanks for the KIP. Nice documentation on all current issues with the
timeout.
You also brought up a good use case for timing out a message. For
applications that collect and send sensor data to Kafka, if the data can't
be sent to Kafka for some reason, the application may prefer to b
Hi, Vahid,
Thanks for the KIP. +1 from me.
Jun
On Wed, Aug 2, 2017 at 2:40 PM, Vahid S Hashemian wrote:
> Hi all,
>
> Thanks to everyone who participated in the discussion on KIP-163, and
> provided feedback.
> The KIP can be found at
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>
Hi, Tom,
Thanks for the KIP. Looks good overall. A few minor comments.
1. In most requests with topic partitions, we nest partitions inside topic.
So, instead of [topic partition_id], we do [topic, [partition_id]] to save
some space.
2. The preferred leader election just tries to move the leader
, Tom Bentley wrote:
> Hi Jun and Dong,
>
> Thanks for your replies...
>
> On 10 August 2017 at 20:43, Dong Lin wrote:
>
> > This is a very good idea. I have updated the KIP-113 so that
> > DescribeDirResponse returns lag instead of LEO.
>
>
> Excellent!
>
>
all about the
> script/command not talking to Zookeeper any more.
>
> Does that make sense to you?
>
> Cheers,
>
> Tom
>
>
> On 11 August 2017 at 16:22, Jun Rao wrote:
>
> > Hi, Tom,
> >
> > One approach is to have a PartitionReassignmentRequest tha
ionRequest
will be responded immediately with a REPLICA_LEADER_ELECTION_IN_PROGRESS
error.
Does this sound good to you?
Thanks,
Jun
On Fri, Aug 11, 2017 at 4:55 AM, Tom Bentley wrote:
> Hi Jun,
>
> Thanks for your reply, I've got a few comment inline...
>
> On 11 August
Hi, Sumant,
1. Yes, it's probably reasonable to require max.message.delivery.wait.ms >
linger.ms. As for retries, perhaps we can set the default retries to
infinite or just ignore it. Then the latency will be bounded by
max.message.delivery.wait.ms. request.timeout.ms is the max time the
request w
Hi, Attila,
Thanks for your interest. I just added you to the contributor list.
Jun
On Wed, Aug 16, 2017 at 1:07 AM, Attila Kreiner wrote:
> Hi All,
>
> I am new here, so I picked an easy issue and created a PR:
> https://github.com/apache/kafka/pull/3669
> https://issues.apache.org/jira/brows
uts. We still won't have a precise way to control delay in just the
> accumulator segment. batch.expiry.ms does not try to abstract. It's very
> specific.
>
> My biggest concern at the moment is implementation complexity.
>
> At this state, I would like to encourage other in
Hi, Rajini,
Thanks for the KIP. A few comments.
1. We have 30+ requests and 30+ error code and growing. So, the combination
can be large. Perhaps it's useful to expire an error metric if it's no
longer updated after some time? We did something similar for the quota
metric.
2. It's a bit weird to
Hi, Rajini,
1. Yammer doesn't seem to support expiration. I guess we can use the Kafka
metric in this case.
Thanks,
Jun
On Thu, Aug 17, 2017 at 4:53 PM, Roger Hoover
wrote:
> Rajini,
>
> The table is super helpful. Thank you.
>
> On Thu, Aug 17, 2017 at 2:16 AM, Rajini Sivaram
> wrote:
>
>
Hi, Rajini,
Thanks for the KIP. Just a minor comment.
Most existing usage of Rate doesn't pass in Count and uses SampledTotal by
default. So should we provide an additional constructor like the following
that uses SampledTotal?
new Meter(rateMetricName, totalMetricName)
Thanks,
Jun
On Thu, Au
Hi, Rajini,
Thanks for the KIP. Looks good overall. Just a couple of minor comments.
1. "The final message from the broker will indicate if authentication
succeeded or failed." Are we doing something special for the final message?
I thought each token response will indicate success or failure in
t; > > > > metrics for the error codes, the number is likely to be much
> > lower
> > > > than
> > > > > > > 30*30, probably less than 100. If we were using Kafka Metrics
> for
> > > > this,
> > > > > > we
> > > &g
t; TOPIC_AUTHORIZATION_FAILED (29) If the user didn't have Alter access to
> the topic.
>
> Also... this command simply starts the leader election, but does not
> wait for it to complete, right? What is the preferred method for an
> admin to check the final result or identify w
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > >
> > >
> > > On Tue, Aug 22, 2017 at 3:08 AM, Ismael Juma
> wrote:
> > >
> > >> Hi all,
> > >>
> > >> The discussion has been g
Hi, Mayuresh,
Since this KIP covers the requirement in KIP-111, could you review it too?
Thanks,
Jun
On Tue, Aug 22, 2017 at 3:04 PM, Jason Gustafson wrote:
> Bump. I'll open a vote in a few days if there are no comments.
>
> Thanks,
> Jason
>
> On Sat, Aug 19, 2017 at 12:28 AM, Ismael Juma
Congratulations, Jiangjie!
Jun
On Wed, Aug 23, 2017 at 10:20 PM, Joel Koshy wrote:
> Hi everyone,
>
> Jiangjie (Becket) Qin has been a Kafka committer in October 2016 and has
> contributed significantly to several major patches, reviews and discussions
> since. I am glad to announce that Becket
>
> > > Now we are introducing another case:
> > > 3. A batch is in retry because we expired an in-flight request before
> it
> > > hits request.timeout.ms.
> > >
> > > The difference between 2 and 3 is that in case 3 likely the broker has
>
Hi, Rajini,
Thanks for the KIP. +1
Jun
On Thu, Aug 24, 2017 at 10:29 AM, Rajini Sivaram
wrote:
> Hi all,
>
> I would like to start vote on KIP-152 to improve diagnostics of
> authentication failures and to update clients to treat authentication
> failures as fatal exceptions rather than transi
out.ms, request.timeout.ms)
> instead of min(remaining delivery.timeout.ms, request.timeout.ms)?
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Fri, Aug 25, 2017 at 9:34 AM, Jun Rao wrote:
>
> > Hi, Becket,
> >
> > Good point on expiring inflight requests.
gt;
> > > > What happens to a batch when retries * (request.timeout.ms +
> > > > retry.backoff.ms) < delivery.timeout.ms and all retries are
> > > exhausted? I
> > > > remember an internal discussion where we concluded that retries can
> be
> > no
> >
Hi, Bhaskar,
Thanks for your interest. Just granted you the wiki permission.
Jun
On Sun, Aug 27, 2017 at 4:37 AM, Bhaskar Gollapudi <
bhaskargollap...@gmail.com> wrote:
> Hi ,
>
> I would like to have have some permissions to create a KIP and start a
> discussion.
>
> I think I was able to cre
h downconversion). It would
> > be
> > > helpful to have topic metrics for the produce message batch size after
> > > decompression (and perhaps compressed as well as that would help
> > understand
> > > the compression ratio).
> > >
> > > 3.
have a lot of retries and
> mixture of PIDs which seem to be pretty complicated.
>
> I think Jason's suggestion will address both concerns, i.e. we fire the
> callback at exactly delivery.timeout.ms, but we will still wait for the
> response to be returned before sending the
Jun,
>
> Thank you, your suggestions sound good. I have updated the KIP.
>
> Regards,
>
> Rajini
>
> On Tue, Aug 29, 2017 at 9:12 PM, Jun Rao wrote:
>
> > Hi, Rajini,
> >
> > Thanks for the updated KIP. I agree that those additional metrics can be
> > usef
Hi, Tom,
Thanks for the KIP. +1. Just one more minor comment. It seems that the
ElectPreferredLeadersResponse
should expect at least 3 other types of errors : (1) request timeout
exception, (2) leader rebalance in-progress exception, (3) can't move to
the preferred replica exception (i.e., preferr
Hi, Jason,
Thanks for the KIP. +1. Just one minor comment. It seems that the new
KafkaPrincipalBuilder
interface should support Configurable and close() as the existing
PrincipalBuilder?
Jun
On Wed, Aug 30, 2017 at 8:51 AM, Jason Gustafson wrote:
> I'd like to open the vote for KIP-189:
> http
at seem reasonable?
>
> -Jason
>
> On Thu, Aug 31, 2017 at 9:53 AM, Jun Rao wrote:
>
> > Hi, Jason,
> >
> > Thanks for the KIP. +1. Just one minor comment. It seems that the new
> > KafkaPrincipalBuilder
> > interface should support Configurable and close
Hi, Charly,
Thanks for your interest. Just granted you the permission to the wiki.
Jun
On Fri, Sep 1, 2017 at 9:22 AM, charly molter
wrote:
> Hi,
>
> I would like to open a KIP and start a discussion.
>
> Could someone please grant me access.
>
> My username is cmolter: https://cwiki.apache.or
Hi, Raijini,
Thanks for the KIP. +1. Just a minor comment.
Since we only measure MessageConversionsTimeMs at the request type level,
is it useful to collect the following metrics at the topic level?
*MBean*:
kafka.server:type=BrokerTopicMetrics,name=FetchMessageConversionsPerSec,topic=([-.\w]+)
gt; <https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > 91+Provide+Intuitive+User+Timeouts+in+The+Producer>
> > > to capture some of the discussion here. Please confirm if it's
> > sufficiently
> > > accurate. Feel free to edit it if you think some
Hi, Tom,
It seems that it's useful to know whether the leader is balanced for each
partition in ElectPreferredLeadersResult, instead of just being attempted?
Thanks,
Jun
On Wed, Sep 6, 2017 at 4:03 PM, Colin McCabe wrote:
> On Wed, Sep 6, 2017, at 01:18, Tom Bentley wrote:
> > Hi Colin,
> >
>
is ready. Thank you!
>
> Many thanks,
>
> Rajini
>
> On Wed, Sep 6, 2017 at 10:52 PM, Jun Rao wrote:
>
> > Hi, Raijini,
> >
> > Thanks for the KIP. +1. Just a minor comment.
> >
> > Since we only measure MessageConversionsTimeMs at the
Hi, Sumant,
Thanks for the KIP. +1.
Just a minor clarification. The KIP says "Batches expire in order
when max.in.flight.request.per.connection==1". Is that true? It seems that
even with max.in.flight.request.per.connection > 1, batches should still
expire in order.
Jun
On Sat, Sep 9, 2017 at 6
ser configures them incorrectly, report a
> ConfigException.
>
>
> On 11 September 2017 at 09:11, Jun Rao wrote:
>
> > Hi, Sumant,
> >
> > Thanks for the KIP. +1.
> >
> > Just a minor clarification. The KIP says "Batches expire in order
>
201 - 300 of 5843 matches
Mail list logo
