prise when I first encountered it.) Maybe the release.py script should
mention it.
best,
Colin
On Fri, Jun 21, 2019, at 08:30, Ismael Juma wrote:
> Hi Colin,
>
> One more thing: the Maven repo was not updated, it seems. Can you fix that?
>
> Ismael
>
> On Fri, Jun 21, 2
I don't think this requires a change in the protocol. It seems like you should
be able to use the high water mark to figure something out here?
best,
Colin
On Fri, Jun 21, 2019, at 04:56, Carlos Manuel Duclos-Vergara wrote:
> Hi,
>
> This is an ancient task, but I feel it is
agree that marking the old AdminClient as deprecated
will be a huge pain. Especially in Scala, where we (currently, at least) have
no way to suppress deprecation warnings. So maybe we should not do that, just
yet.
best,
Colin
On Fri, Jun 21, 2019, at 15:41, Matthias J. Sax wrote:
> I sti
Hi Ismael,
Good idea. I added a section on this.
best,
Colin
On Fri, Jun 21, 2019, at 17:30, Ismael Juma wrote:
> Thanks Colin! Maybe we should mention that restarts are much faster when
> you have a lot of partitions:
> https://issues.apache.org/jira/browse/KAFKA-7283
>
Vote thread:
https://www.mail-archive.com/dev@kafka.apache.org/msg98814.html
I'll continue with the release process and the release announcement will follow
in the next few days.
thanks,
Colin
On Mon, Jun 24, 2019, at 01:17, Mickael Maison wrote:
> Thanks Colin for making a new RC f
Hi Stephane,
Sounds interesting! Do you have a link to the video you made for 2.3?
best,
Colin
On Sun, Jun 23, 2019, at 15:10, Stephane Maarek wrote:
> The video is ready :) waiting for the release of Kafka 2.3 to make it
> public. @colin if you want to link it in the blog at some
eprecation, and Migration Plan"
best,
Colin
On Mon, Jun 24, 2019, at 14:04, Justine Olshan wrote:
> Hello,
> This is the discussion thread for KIP-480: Sticky Partitioner.
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-480%3A+Sticky+Partitioner
>
> Thank you,
> Justine Olshan
>
Satish, A. Sophie Blee-Goldman, asutosh936, Bill Bejeck, Bob Barrett,
Boyang Chen, Brian Bushree, cadonna, Casey Green, Chase Walden, Chia-Ping Tsai,
Chris Egerton, Chris Steingen, Colin Hicks, Colin Patrick McCabe, commandini,
cwildman, Cyrus Vafadari, Dan Norwood, David Arthur, Dejan
video about 2.3 here:
https://www.youtube.com/watch?v=YutjYKSGd64
cheers,
Colin
On Tue, Jun 25, 2019, at 09:40, Colin McCabe wrote:
> The Apache Kafka community is pleased to announce the release for
> Apache Kafka 2.3.0.
> This release includes several new features, including:
>
arer what is going on.
best,
Colin
On Mon, Jun 24, 2019, at 18:32, Boyang Chen wrote:
> Thank you Justine for the KIP! Do you mind creating a corresponding JIRA
> ticket too?
>
> On Mon, Jun 24, 2019 at 4:51 PM Colin McCabe wrote:
>
> > Hi Justine,
> >
> > Th
's focus on KIP-455 here. We
have more resources now so I think we'll be able to get it done soonish.
best,
Colin
On Tue, Jun 25, 2019, at 08:09, Viktor Somogyi-Vass wrote:
> Hi All,
>
> I have added another improvement to this, which is to limit the parallel
> leader mov
Thanks Justine! You might want to update the "JIRA" link on the KIP so that it
links to this.
cheers,
Colin
On Tue, Jun 25, 2019, at 11:59, Justine Olshan wrote:
> Thank you for looking at my KIP!
>
> I will get to work on these changes.
>
> In addition, here is
Well, this is a generic partitioner method, so it shouldn't dictate any
particular behavior.
Colin
On Tue, Jun 25, 2019, at 12:04, Justine Olshan wrote:
> I also just noticed that if we want to use this method on the keyed record
> case, I will need to move the method outside of the
in. Weird...
>
> On Tue, Jun 25, 2019 at 1:41 PM Justine Olshan wrote:
>
> > I came up with a good solution for this and will push the commit soon. The
> > repartition will be called only when a partition is not manually sent.
> >
> > On Tue, Jun 25, 2019 at 1:39 PM Col
never really been
implemented (yet?).
best,
Colin
On Tue, Jun 25, 2019, at 15:46, Boyang Chen wrote:
> Actually, after a second thought, I think it actually makes sense to
> support auto upgrade through admin client to help use get api version
> from
> broker.
> A draft
+1 (binding).
C.
On Mon, Jun 24, 2019, at 08:10, Andy Coates wrote:
> Hi all,
>
> KIP updated:
> - No deprecation
> - Factory method back onto Admin interface
>
> I'd like to kick off another round of voting please.
>
> Thanks,
>
> Andy
>
> On Mon, 24 Jun 2019 at 16:03, Andy Coates wrote:
>
On Wed, Jun 19, 2019, at 03:36, Stanislav Kozlovski wrote:
> Hey there Colin,
>
> Thanks for the work on this KIP. It is a much-needed improvement and I'm
> excited to see it. Sorry for coming in so late to the discussion, I have
> one question to better understand th
On Tue, Jun 25, 2019, at 18:37, Jason Gustafson wrote:
> Hi Colin,
>
> Took another pass on the KIP. Looks good overall. A few questions below:
>
> 1. I wasn't clear why `currentReplicas` is an optional field. Wouldn't we
> always have a current set of replicas?
Good
Hi all,
I would like to start a discussion for KIP-482:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-482%3A+The+Kafka+Protocol+should+Support+Optional+Fields
cheers,
Colin
On Wed, Jun 26, 2019, at 12:02, Jason Gustafson wrote:
> Hi Colin,
>
> Responses below and another question:
>
> > I guess the thought process here is that most reassignment tools want to
> > know about all the reassignments that are going on. If you don't know all
e is
that we'll want a way of knowing what target replicas are currently being
worked on. So maybe we'll have to add a field to the structures returned by
listPartitionReassignments.
best,
Colin
On Wed, Jun 26, 2019, at 06:20, Viktor Somogyi-Vass wrote:
> Hey Colin,
>
> I
ca was one of the original ones, or one of the ones we're
reassigning to. A secondary reason is because nothing useful will come of
telling users they have a bunch of replicas that don't really exist. We may
not have even started copying the first byte over to a target replica, so it
lled when an explicit partition id has been provided.
Agreed.
best,
Colin
>
> Ismael
>
> On Mon, Jun 24, 2019, 2:04 PM Justine Olshan wrote:
>
> > Hello,
> > This is the discussion thread for KIP-480: Sticky Partitioner.
> >
> >
> > https://cwiki.
Hi Mickael,
Thanks for pointing this out. It should be fixed now.
best,
Colin
On Mon, Jul 1, 2019, at 09:14, Mickael Maison wrote:
> Colin,
>
> The javadocs links are broken:
> The requested URL /23/javadoc/index.html was not found on this server.
>
> It's the 3rd tim
be using deprecation when appropriate,
regardless of the potential annoyances to users. But I'm not sure deprecating
this method is really worth it.
best,
Colin
>
> Can you elaborate?
>
> IMHO, just adding a statement to JavaDocs is a little weak, and at some
> point, we
On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> > Not sure, if I understand the argument?
> >
> > Why would anyone need to support multiple client side versions?
> > Clients/brokers are forward/backward c
On Tue, Jul 2, 2019, at 02:55, Tom Bentley wrote:
> Hi Colin,
>
> In the example given, of a FooResponse, both the optional fields have the
> tag 0x0001. The text says "This number must be unique within the context it
> appears in.". My first thought was the example t
On Tue, Jul 2, 2019, at 10:47, Stanislav Kozlovski wrote:
> Hey there, I need to start a new thread on KIP-455. I think there might be
> an issue with the mailing server. For some reason, my replies to the
> previous discussion thread could not be seen by others. After numerous
> att
On Wed, Jul 3, 2019, at 11:22, Stanislav Kozlovski wrote:
> Hey Colin,
>
> Thanks for the detailed reply!
>
> > Not really. Cruise Control, for example, tries to update the znode even
> > when it's not empty. This doesn't work, of course. This is an exis
Hi M. Manna,
I left a review. Take a look.
Sorry for the delays.
best,
Colin
On Mon, Jul 8, 2019, at 14:38, M. Manna wrote:
> Hello,
>
> A few requests have been sent already. Could this please be reviewed ? Our
> business implementation is holding due to this change.
>
&g
Hi M,
The RoundRobinPartitioner added by KIP-369 doesn't interact with this KIP. If
you configure your producer to use RoundRobinPartitioner, then the
DefaultPartitioner will not be used. And the "sticky" behavior is implemented
only in the DefaultPartitioner.
regards,
Colin
retty easy to add (and it wouldn't have to
implemented right away in the first PR, of course.) It would be an option for
people who wanted to configure this behavior.
best,
Colin
On Wed, Jul 10, 2019, at 08:48, Justine Olshan wrote:
> Hi M,
>
> I'm a little confused by wh
StickyRoundRobinPartitioner class that just implements the
sticky behavior regardless of whether the key is null or not. It would just be
a standalone custom partitioner class that could be configured if people wanted
this.
best,
Colin
On Tue, Jul 9, 2019, at 17:15, Justine Olshan wrote
;s no reason not
>to support this, I think.
We should add some documentation explaining the difference between server-side
and client-side auto-creation. Without documentation, an admin might think
that they had disabled all forms of auto-creation by setting the -side setting
to false-- but this is
On Tue, Jul 9, 2019, at 15:29, Jose Armando Garcia Sancio wrote:
> Thanks Colin for the KIP. For my own edification why are we doing this
> "Optional fields can have any type, except for an array of structures."?
> Why can't we have an array of structures?
Optional fields
//github.com/apache/kafka/pull/6997/files. The most important lines
> are in the append method of the RecordAccumulator and doSend in
> KafkaProducer.
Thanks for the explanation.
>
> Colin, I think this makes sense to me except for the name
> StickyRoundRobinPartitioner seems to
replication.throttled.rate).
> KIP-455 will remove Broker Level throttle only when no more reassignments in
> the cluster? race conditions with another newly submitted reassignment with
> throttle? actually general handling of race conditions of concurrent
> submissions of reassignme
g inside the
> full replica set, we can ensure that we end up with
> replicas==targetReplicas once we empty out removingReplicas from the full
> replica set.
>
> > Also I still hope this KIP-455 can provide a feature/solution of clean
> cancel/rollback as much as possible.
> I ag
On Mon, Jul 15, 2019, at 11:51, Jason Gustafson wrote:
> Hi Colin,
>
> A few more questions below:
>
> 1. The KIP says that the --zookeeper option will be removed from
> kafka-reassign.sh. Do you mean that it will be deprecated and eventually
> removed?
Keeping the --zook
removingReplicas" from the
> existing partition assignments?
The order of the replicas in the "replicas" set determines which one is the 1st
preferred leader, 2nd preferred leader, and so on, just like now. This is also
conveyed in the AlterPartitionReassignments call by the
+1 (binding). Thanks for the KIP, Anastasia.
best,
Colin
On Fri, Jul 12, 2019, at 10:09, Jason Gustafson wrote:
> +1 Thanks for the KIP!
>
> -Jason
>
> On Fri, Jul 12, 2019 at 9:59 AM Gwen Shapira wrote:
>
> > +1 (binding)
> >
> > Looks great to me. T
Thanks, Stanislav. Let's restart the vote to reflect the fact that we've made
significant changes. The new vote will go for 3 days as usual.
I'll start with my +1 (binding).
best,
Colin
On Wed, Jul 17, 2019, at 08:56, Stanislav Kozlovski wrote:
> Hey everybody,
>
>
Hi all,
With three non-binding +1 votes from Viktor Somogyi-Vass, Robert Barrett, and
George Li, and 3 binding +1 votes from Gwen Shapira, Jason Gustafson, and
myself, the vote passes. Thanks, everyone!
best,
Colin
On Fri, Jul 19, 2019, at 08:55, Robert Barrett wrote:
> +1 (non-bind
ns it can be hooked into traditional metrics / reporting systems.
best,
Colin
On Mon, Jul 22, 2019, at 03:12, Jose M wrote:
> Hello,
>
> I didn't get any feedback on this small KIP-490
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-490%3A+log+when+consumer+grou
What is an MDT mirror server?
best,
Colin
On Thu, Jul 18, 2019, at 18:29, Harry k wrote:
> Hi,
> How to check version information for Kafka that is being used on the MDT
> Mirror servers? Is their any command to check that.I have any only access
> to Kafka and zookeeper servers throu
is to be undone after a certain amount of time, or under certain
conditions, that seems like something that would be more effectively done by an
external system, rather than putting all these policies into Kafka.
best,
Colin
On Fri, Jul 19, 2019, at 18:23, George Li wrote:
> Hi Satish
broker in question.
best,
Colin
On Fri, Jul 26, 2019, at 09:43, Jason Gustafson wrote:
> Hi All,
>
> I have written a proposal to change the way leaders make ISR
> modifications:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-497%3A+Add+inter-broker+API+to+alter+ISR.
> H
> > > bump
> > > up the version number in the json value?
The change to the zNode is backwards compatible, though. Older brokers will
continue to work, but just ignore the new fields. If we bump that version
number, then downgrades will require hand-editing zookeeper. (
rth it to
restrict support to post-KIP-464 brokers, if we could avoid creating more
configs.
best,
Colin
> On Wed, Jul 31, 2019 at 9:10 AM Mickael Maison
> wrote:
>
> > Hi Justine,
> >
> > We can rely on KIP-464 which allows to omit the partition count or
> >
Hi all,
I've written a KIP about removing ZooKeeper from Kafka. Please take a look and
let me know what you think:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum
cheers,
Colin
Hi Harsha,
Thanks for the heads up. This should be fixed-- give it another try.
best,
Colin
On Thu, Aug 1, 2019, at 14:15, Harsha wrote:
> Hi Colin,
> Looks like KIP is missing the images , links are broken.
> Thanks,
> Harsha
>
> On Thu, Aug 1, 2019, at 2:0
On Thu, Aug 1, 2019, at 12:00, Jun Rao wrote:
> Hi, Colin,
>
> 10. Sounds good.
>
> 13. Our current convention is to bump up the version of ZK value if there
> is any format change. For example, we have bumped up the version of the
> value in /brokers/ids/nnn multiple t
efore actually removing them. I'm happy
> to change this either way if it's preferred.
I think Jason was proposing deprecating (but NOT removing) the old arguments in
the next release.
Thanks for tackling this. +1 for the KIP.
best,
Colin
> -mitch
>
> On Tue, Ju
On Fri, Aug 2, 2019, at 07:50, Ryanne Dolan wrote:
> Thanks Colin, interesting KIP.
>
> I'm concerned that the KIP does not actually address its stated
> motivations. In particular, "Simpler Deployment and Configuration" are not
> really achieved, given that:
Hi Ryanne,
Good idea. I added some of this discussion to the KIP-- in particular, more
about controller failover.
cheers,
Colin
On Fri, Aug 2, 2019, at 13:28, Ryanne Dolan wrote:
> Thanks Colin, that helps. Can we add some of this to the KIP?
>
> Ryanne
>
> On Fri, Aug 2, 2
On Fri, Aug 2, 2019, at 16:33, Jose Armando Garcia Sancio wrote:
> Thanks Colin for the detail KIP. I have a few comments and questions.
>
> In the KIP's Motivation and Overview you mentioned the LeaderAndIsr and
> UpdateMetadata RPC. For example, "updates which the contro
On Mon, Aug 5, 2019, at 07:49, Viktor Somogyi-Vass wrote:
> Hey Colin,
>
> I think this is a long-awaited KIP, thanks for driving it. I'm excited to
> see this in Kafka once. I collected my questions (and I accept the "TBD"
> answer as they might be a bit deep for t
On Mon, Aug 5, 2019, at 10:02, Tom Bentley wrote:
> Hi Colin,
>
> Thanks for the KIP.
>
> Currently ZooKeeper provides a convenient notification mechanism for
> knowing that broker and topic configuration has changed. While KIP-500 does
> suggest that incremental metadata
I think it would be useful to have this in AdminClient. Especially if we
implement KIP-496: Administrative API to delete consumer offsets. It would be
odd to have a way to delete consumer offsets in AdminClient, but not to create
them. What do you think?
best,
Colin
On Sun, Aug 4, 2019
kafka-topics.sh.
Trusting them not to set a certain config value seems minor in comparison,
right?
best,
Colin
On Tue, Aug 6, 2019, at 10:49, Harsha Chintalapani wrote:
> Hi,
> Even with policies one needs to implement that, so for every user who
> doesn't want a producer to
ified, and
not specific to reassigning partitions.
regards,
Colin
On Tue, Aug 6, 2019, at 10:57, Koushik Chitta wrote:
> Hey Colin,
>
> Can the ListPartitionReassignmentsResult include the status of the
> current reassignment progress of each partition? A reassignment can be
> in
Thanks for the bug report, Mickael. As Matthias said, it should be fixed now.
I also updated the CVEs page.
cheers,
Colin
On Wed, Jul 31, 2019, at 02:53, Mickael Maison wrote:
> Hi,
>
> It looks like the protocol page was not updated. It still only lists 2.2 APIs.
> http://kafk
his, and I think it was useful. NFS also supported (supports?) a mode
where you just pass whatever user ID you want and the system believes you.
These things clearly don't protect against malicious users, but they can help
set up policies when needed.
best,
Colin
>
> Thanks,
> Harsha
On Tue, Aug 6, 2019, at 21:38, Harsha Ch wrote:
> Hi Colin,
> "Hmm... I'm not sure I follow. Users don't have to build their own
> tooling, right? They can use any of the shell scripts that we've shipped
> in the last few releases. For example, if any of your u
On Wed, Aug 7, 2019, at 09:24, Harsha Ch wrote:
> On Tue, Aug 06, 2019 at 11:46 PM, Colin McCabe < cmcc...@apache.org > wrote:
>
> > On Tue, Aug 6, 2019, at 21:38, Harsha Ch wrote:
> >>
> >> Hi Colin,
> >> "Hmm... I'm not sure I follow.
On Fri, Aug 2, 2019, at 20:02, George Li wrote:
> Hi Colin,
> Thanks for looking into this KIP. Sorry for the late response. been busy.
>
> If a cluster has MAMY topic partitions, moving this "blacklist" broker
> to the end of replica list is still a rather &
started after some time.
>
This has definitely been an issue in the past, I agree. Thankfully, we
recently did improve the robustness of the ReplicaFetcher. Check out "KIP-461:
Improve Replica Fetcher behavior at handling partition failure."
cheers,
Colin
>
>
> Than
On Wed, Aug 7, 2019, at 12:48, George Li wrote:
> Hi Colin,
>
> Thanks for your feedbacks. Comments below:
> > Even if you have a way of blacklisting an entire broker all at once, you
> >still would need to run a leader election > for each partition where you
> >
Hi Koushik,
The vote for this KIP already passed.
See https://www.mail-archive.com/dev@kafka.apache.org/msg99636.html
best,
Colin
On Thu, Aug 8, 2019, at 10:50, Koushik Chitta wrote:
> Thanks Colin, George. Can we restart the voting for this KIP.
>
> Thanks,
> Koushik
>
n we can have Originator#CLIENT and
Originator#BROKER.
It's hard to understand what Action#count is for. If we want to log something
like "failed to authorize deleting 123 partitions", it would be better to just
let the caller supply some custom text in Authorizer#logFailure.
Tha
I agree that limiting the scope of the KIP would be good.
The configuration is actually bootstrap.servers with an S, though.
I actually like --bootstrap-servers slightly better than --bootstrap-server,
although I don't feel that strongly about either. ;)
best,
Colin
On Thu, Aug 8, 201
provider, so that they can integrate their custom SSL
infra with more applications than just Kafka. So I'm not sure how big the
audience for the proposed new configurations would be.
regards,
Colin
On Thu, Aug 8, 2019, at 15:29, Maulin Vasavada wrote:
> Hi Harsha
>
> We don&#x
f the broker JVMs.
best,
Colin
On Wed, Aug 7, 2019, at 10:37, Mickael Maison wrote:
> Thank Colin for kickstarting this initiative.
>
> Just one question.
> - A nice feature of Zookeeper is the ability to use chroots and have
> several Kafka clusters use the same Zookeeper ensemble. Is
if the new mechanism is not
supported.
>From a compatibility point of view, if we rely on a new field in
>CreateTopicsRequest, we definitely won't be able to use the
>CreateTopicsRequest mechanism against any broker but a 2.4+ one. That's
>probably fine (and consistent with som
Hi Gabor,
What is it that you want to do here? If you just want to check that the
partitions exist, but not fetch any data, you could use
AdminClient#describeTopics for that. If you want to create the topics, you
could use AdminClient#createTopics.
best,
Colin
On Fri, Aug 9, 2019, at 11
+1 (binding)
cheers,
Colin
On Fri, Aug 9, 2019, at 09:56, Ron Dagostino wrote:
> +1 (non-binding)
>
> The simplest of KIPs, with perhaps the biggest impact. Like removing
> the thorn from the soles of my feet.
>
> Thanks for doing it.
>
> > On Aug 9, 2019, at 1
Hi all,
I've made some updates to this KIP. Specifically, I wanted to avoid including
escape bytes in the serialization format, since it was too complex. Also, I
think this is a good opportunity to slim down our variable length fields.
best,
Colin
On Thu, Jul 11, 2019, at 20:52,
necessary APIs for managing
offsets.
Best,
Colin
On Mon, Aug 12, 2019, at 07:39, Jungtaek Lim wrote:
> My feeling is that I didn't explain the use case for Spark properly and
> hence fail to explain the needs. Sorry about this.
>
> Spark leverages the single instance of Kaf
seems to be low. The update interval can also be configured.
Best,
Colin
On Sun, Aug 11, 2019, at 16:43, Michael Carter wrote:
> Hi Rajini,
>
> I just thought I'd let you know I've sorted through my issue now. It turns
> out that I was doing something silly. The SSL ha
+1. Thanks, Manikumar.
Colin
On Mon, Aug 12, 2019, at 08:25, Matthias J. Sax wrote:
> Thanks Manikumar! SGTM.
>
>
> On 8/12/19 7:54 AM, Manikumar wrote:
> > Hi all,
> >
> > I would like to volunteer to be the release manager for our next time-based
> > f
+1 for better access control here. In general, impersonating another user seems
like it’s equivalent to super user access.
Colin
On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> Hi Viktor,
>
> As per the KIP, It's not only superuser, any user with required permissions
>
On Mon, Aug 12, 2019, at 14:54, Jungtaek Lim wrote:
> Thanks for the feedbacks Colin and Matthias.
>
> I agree with you regarding getting topics and partitions via AdminClient,
> just curious how much the overhead would be. Would it be lighter, or
> heavier? We may not want to
On Mon, Aug 12, 2019, at 11:22, Jason Gustafson wrote:
> Hi Colin,
>
> Thanks for the KIP! This is a significant improvement. One of my personal
> interests in this proposal is solving the compatibility problems we have
> with the internal schemas used to define consumer offsets
That is a good point-- we should get KIP-396 voted on. I will review it today.
best,
Colin
On Tue, Aug 13, 2019, at 05:58, Gabor Somogyi wrote:
> I've had a look on KIP-396 and until now only 1 binding vote arrived. Hope
> others would consider it as a good solution...
>
>
Hi Jason,
Thanks for the KIP.
Is there ever a desire to delete all the offsets for a given group? Should the
protocol and tools support this?
+1 (binding)
best,
Colin
On Mon, Aug 12, 2019, at 10:57, Guozhang Wang wrote:
> +1 (binding).
>
> Thanks Jason!
>
> On Wed, Aug 7
map? If so, we should specify that in the JavaDoc.
isolationLevel seems like it should be an enum rather than a string. The
existing enum is in org.apache.kafka.common.requests, so we should probably
create a new one which is public in org.apache.kafka.clients.admin.
best,
Colin
On Mon, Mar
= true, false. LIST_AUTHORIZED =
false, false. Would there be anything lost versus having the enum?
best,
Colin
On Wed, Aug 14, 2019, at 06:29, Mickael Maison wrote:
> Hi Rajini,
>
> Thanks for the KIP!
> I really like that authorize() will be able to take a batch of
> request
Thanks, Mickael. +1 (binding)
best,
Colin
On Wed, Aug 14, 2019, at 12:07, Gabor Somogyi wrote:
> +1 (non-binding)
> I've read it through in depth and as Jungtaek said Spark can make good use
> of it.
>
> On Wed, 14 Aug 2019, 17:06 Jungtaek Lim, wrote:
>
> > +1
tricky to get right and involves "racing
against producers" and wasted double I/Os
Of course, one other question is how frequently we add new disk drives
to an existing broker. In this case, you might reasonably want disk
rebalancing to avoid overloading the new disk(s) with writes.
che
Just a note: KIP-144 added exponential backoff for broker reconnect
attempts, configured via reconnect.backoff.max.ms.
cheers,
Colin
On Sat, Jun 10, 2017, at 08:42, 东方甲乙 wrote:
> -- 原始邮件 --
> 发件人: "东方甲乙";<254479...@qq.com>;
> 发送时间: 20
we
will remove AdminClient#apiVersions for now, until the next release. It
will still be possible to get version information with the existing
kafka-broker-api-versions.sh script.
best,
Colin
On Sat, Jun 3, 2017, at 01:08, Ismael Juma wrote:
> Hi Colin,
>
> Thanks for the feedback.
t.
cheers,
Colin
That's a good point. I revised the KIP to add metrics for all the group
states.
best,
Colin
On Fri, Jul 21, 2017, at 12:08, Guozhang Wang wrote:
> Ah, that's right Jason.
>
> With that I can be convinced to add one metric per each state.
>
> Guozhang
>
> O
te name publicly in these metrics,
perhaps it makes sense to do this rename now. Thoughts?
best,
Colin
On Fri, Jul 21, 2017, at 13:52, Colin McCabe wrote:
> That's a good point. I revised the KIP to add metrics for all the group
> states.
>
> best,
> Colin
>
>
>
Thanks for the explanation. I guess maybe we should just keep the group
names as they are, then?
best,
Colin
On Wed, Jul 26, 2017, at 11:25, Guozhang Wang wrote:
> To me `PreparingRebalance` sounds better than `StartingRebalance` since
> only by the end of that stage we have formed a new
How about PreparingRebalance / CompletingRebalance?
cheers,
Colin
On Fri, Aug 4, 2017, at 09:03, Ismael Juma wrote:
> I agree that we should make them consistent. I think RebalanceJoin and
> RebalanceAssignment are reasonable names. I think they are a bit more
> descrip
have no more members,
but the offsets have not yet expired.
Of course, this KIP is just exposing the metrics, not changing how
groups work in any way.
Maybe we should start a vote, if this looks good to everyone?
best,
Colin
>
> If so, this makes sense to me.
>
> Thanks,
&g
group+rebalances+in+progress
best,
Colin
With +1s from Bill Bejeck, Apurva Mehta, Mickael Maison, Gwen Shapira,
Ismael Juma, Guozhang Wang, and Jason Gustafson, and no +0 or -1s, the
vote passes.
cheers,
Colin
On Wed, Aug 16, 2017, at 13:08, Jason Gustafson wrote:
> +1
>
> On Sun, Aug 13, 2017 at 5:15 PM, Guozhang Wang
atches in
a day or two-- it would be great to get some feedback. Check out
https://cwiki.apache.org/confluence/display/KAFKA/Fault+Injection
best,
Colin
401 - 500 of 2168 matches
Mail list logo
