Just to give a little context here, the main reason for having the
AdminClient#create method is so that end-users didn't have to import
KafkaAdminClient. In general, users should be interacting with the AdminClient
API, not with the implementation class(es).
Also, I have to grudgingly agree th
to 55
> minutes."
>
> Ismael
>
> On Tue, Jun 18, 2019 at 1:10 PM Colin McCabe wrote:
>
> > Hi all,
> >
> > I've written up a preliminary blog post about the upcoming Apache Kafka
> > 2.3.0 release. Take a look and let me know what you think.
> >
anyway and ran quickstart on the 2.11 binary.
> >
> > Looks good!
> >
> > On Sun, Jun 23, 2019 at 3:06 PM Jakub Scholz wrote:
> > >
> > > +1 (non-binding). I used the binaries and run some of my tests against
> > > them.
> > >
> > > On Thu
kaWbp1Cnfo4&t=10s). Having
> > summaries like this in both formats -- blog and video -- for every release
> > would be helpful as different people have different preferences.
> >
> > Ron
> >
> > On Tue, Jun 18, 2019 at 8:20 PM Colin McCabe wrote:
> >
&
Hi Justine,
Thanks for the KIP. This looks great!
In one place in the KIP, you write: "Remove
testRoundRobinWithUnavailablePartitions() and testRoundRobin() since the round
robin functionality of the partitioner has been removed." You can skip this
and similar lines. We don't need to descri
The Apache Kafka community is pleased to announce the release for Apache Kafka
2.3.0.
This release includes several new features, including:
- There have been several improvements to the Kafka Connect REST API.
- Kafka Connect now supports incremental cooperative rebalancing.
- Kafka Streams now
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
t;> way
> >>>> to update a reassignment while it is still in progress.
> >>>>
> >>>> -Jason
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Apr 8, 2019 at 11:14 PM George Li >
the JIRA ticket:
> https://issues.apache.org/jira/browse/KAFKA-8601
>
> Thanks again,
> Justine
>
> On Tue, Jun 25, 2019 at 11:55 AM Colin McCabe wrote:
>
> > Hi Justine,
> >
> > The KIP discusses adding a new method to the partitioner interface.
> >
sticky (no key, no set
> partition) check. Not a big problem, but something to keep in mind.
> Perhaps, we should encapsulate the sticky vs. not behavior inside the
> method? More things to think about.
>
> On Tue, Jun 25, 2019 at 11:55 AM Colin McCabe wrote:
>
> > Hi
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
kafka.api.ApiVersion is an internal class, not suitable to exposing through
AdminClient. That class is not even accessible without having the broker jars
on your CLASSPATH.
Another question is, what is the groupId parameter doing in the call? The API
versions are the same no matter what consu
+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:
>
opics are not
really relevant.
After all, the partitions for a particular topic are probably spread across the
whole system. Topics are a useful administrative concept, but not really that
relevant to the world of partition reassignment (or maybe I'm missing
something?)
best,
Colin
>
u think about an ease of use improvement where we
> > allow a user to cancel all reassignments for a topic without specifying its
> > partitions? Essentially, we could cancel all reassignments for a topic if
> > the Partitions field in AlterPartitionAssignmentsRequest is null.
>
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
plicas and add it to replicas. This is another ZK write, of
course. I don't think this is really a problem in practice because when we're
creating the client metadata message, we can simply enforce that anything in
the ISR must be in the replica set and not in the targetReplica set.
be
k section so in my
> understanding KIP-455 won't touch that :).
> Let me know if I'm missing any points here.
>
> Viktor
>
> On Tue, Jun 25, 2019 at 9:02 PM Colin McCabe wrote:
>
> > Hi Viktor,
> >
> > Now that the 2.3 release is over, we're
doesn't make sense to treat it like a normal replica that's not in the ISR
because it's lagging slightly.
best,
Colin
>
> (Sorry if I'm being dense, it's just not clear to me exactly what the
> expected transitions are from here.)
>
>
> Thanks,
On Thu, Jun 27, 2019, at 01:31, Ismael Juma wrote:
> Thanks for the KIP Justine. It looks pretty good. A few comments:
>
> 1. Should we favor partitions that are not under replicated? This is
> something that Netflix did too.
This seems like it could lead to cascading failures, right? If a parti
e in a row this happens (2.1 and 2.2 had the same
> issue at release). Last time, Guozhang confirmed this step is in the
> release process but maybe this needs to be highlighted
>
> On Tue, Jun 25, 2019 at 8:22 PM Colin McCabe wrote:
> >
> > Thanks to everyone who revi
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 compatible anyway.
When you're using many different libraries, it is helpful if they don't imp
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
le message. I will try to
clarify the text here.
best,
Colin
>
> Thanks,
>
> Tom
>
> On Wed, Jun 26, 2019 at 10:01 PM Colin McCabe wrote:
>
> > Hi all,
> >
> > I would like to start a discussion for KIP-482:
> >
> > https://cwiki.a
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
> attempts, Colin su
we wait until the partitionB
> > > move finishes as well?
>
> > We wait for the partitionB move to finish. The rationale is that we don't
> > really ever know what is in ZK (it could change at any time, and our writes
> > to ZK could race with someone
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.
>
>
>
> On Thu, 4 Ju
;> I made some changes to the KIP.
> > >> The idea is to clean up the code, make behavior more explicit, provide
> > >> more flexibility, and to keep default behavior the same.
> > >>
> > >> Now we will change the partition in onNewBatch, and spec
good feature and having
> > that extended to RoundRobinPartitioner means 1 less KIP in the future.
> >
> > Would it be appropriate to extend the support to RoundRobinPartitioner too?
> >
> > Thanks,
> >
> > On Tue, 9 Jul 2019 at 17:24, Colin McCabe w
+1 (binding). Thanks, Justine!
ComputedPartition#get probably should be ComputedPartition#partition or
something. We typically name accessors the same as the variables that are
being accessed.
As we discussed in the other thread, one minor addition that might make this
KIP even better is a S
Hi Justine,
Thanks for the KIP. This seems like a good step towards removing server-side
topic auto-creation.
We should add included "client-side" to the title of the KIP somewhere, to make
it clear that we're talking about client-side auto creation.
The KIP says:
> In order to automatically
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 are serialized starting w
the first partition in time, the
> > producer will send a single record batch. In the worse case, it can be that
> > every other batch has only a single record. Is this correct? If so, could
> > we avoid that?
> >
> > Jun
> >
> > On Thu, Jul 11, 2019 at 5:23
On Sat, Jul 13, 2019, at 17:54, George Li wrote:
> Hi Stanislav,
>
> sorry for the late reply. comments below:
>
> > Thanks for the reminder. A lot of your suggestions are outlined in the
> > "Future Work" section of KIP-455. The pointer towards different
> > ReplicaFetcher thread pools is inte
On Mon, Jul 15, 2019, at 14:31, Stanislav Kozlovski wrote:
> Hey George,
>
> > Different replica threads for throttling
> The reason we can't support throttling for reassigning partitions right now
> is because we have no good way of telling whether a replica is part of an
> ongoing reassignment o
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 --zookeeper flag here would be
On Sat, Jul 13, 2019, at 17:54, George Li wrote:
> I just take a look at the updated KIP-455 again. I noticed
> this "targetReplicas" is removed and instead, put "addingReplicas" &
> "removingReplicas". So where does the new reassigned "targetReplicas"
> is stored? When all replicas in ISR, and
+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. Thank you for the KIP.
> >
> > On Mon, Ju
>
> As always, you can re-read the KIP here
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-455%3A+Create+an+Administrative+API+for+Replica+Reassignment
>
> Best,
> Stanislav
>
> On Wed, May 22, 2019 at 6:12 PM Colin McCabe wrote:
>
> > Hi George,
> >
son Gustafson
> > wrote:
> > >
> > > +1 Thanks for the KIP. Really looking forward to this!
> > >
> > > -Jason
> > >
> > > On Wed, Jul 17, 2019 at 1:41 PM Colin McCabe wrote:
> > >
> > > > Thanks, Stanislav. Let's r
Hi Jose,
One issue that I see here is that the number of log messages could be huge.
I've seen people create tens of thousands of consumer groups. People can also
have settings that create pretty small log files. A message per log file per
group could be quite a lot of messages.
A log messa
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 through putty.Any
We still want to give the "blacklisted" broker the leadership if nobody else is
available. Therefore, isn't putting a broker on the blacklist pretty much the
same as moving it to the last entry in the replicas list and then triggering a
preferred leader election?
If we want this to be undone a
Hi Jason,
This looks good.
If the AlterIsr request returns a higher ZK version than the one the broker
currently has, will the broker use that as its new ZK version? I suppose this
could happen if some of the updates the controller pushed out were not received
or not received yet by the broke
Of course
downgrade isn't officially supported, but it would be nice not to break it if
we don't need to...) Changing the version number would also create problems
during a rolling upgrade.
best,
Colin
> > >
> > > Jun
> > >
> > > On Mon, Jul 22, 2019
s be clear to the user. Changing the code
> > to
> > > > have
> > > > > > the
> > > > > > > > producer's configurations take precedence is possible, but I
> > was
> > > > > > wondering
> > > > > >
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
> > those
> > > > > unneeded replicas.
> >
> > Right. Let's add this.
> >
> > > > > 13. Since we changed the format of the topics/[topic] zNode, should
> > we bump
> > > > > up the version number in the json value?
>
On Wed, Jul 31, 2019, at 05:26, Mitchell wrote:
> Hi Jason,
> Thanks for looking at this!
>
> I wasn't exactly sure what to put in the compatibility section. I wrote
> the KIP thinking that we should probably mark the old arguments for
> deprecation for a release or two before actually removing t
e less bandwidth to do
so. It will even be possible for the brokers to cache this state locally in a
file on disk, so that broker startup can be much faster. All of these are
important to scaling Kafka in the future.
Treating metadata as a log avoids a lot of the complex failure corner cases
019 at 12:23 PM Colin McCabe wrote:
>
> > 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, "S
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 controller pushes, such
> as Le
https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging
> > > > >,
> > > > including the new request protocols and how they are interacting in the
> > > new
> > > > cluster. For a complicated change lik
> what
> > > > > we did in KIP-98
> > > > > <
> > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging
> > > >
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, at
her from clients by server side config.
> > Server side configs of default topic, partitions should take higher
> > precedence and client shouldn't be able to create a topic with higher
> >
> > no.of
> >
> > partitions, replication than what server config specifie
the new binary. Otherwise, the
> reassignment task may not be completed if the controller changes to a
> broker still on the old binary.
> IBP is one way to achieve that. The main thing is that we need some way
> for the controller to deal with the new ZK fields. Dealing with the
&g
a.apache.org/protocol
>
> Thanks
>
> On Tue, Jul 2, 2019 at 2:05 AM Colin McCabe wrote:
> >
> > Hi Mickael,
> >
> > Thanks for pointing this out. It should be fixed now.
> >
> > best,
> > Colin
> >
> > On Mon, Jul 1, 2019, at 09:14
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
't want to implement
client-side topic creation in the consumer in "rejected alternatives." Maybe
Justine can add more context here in the KIP.
The last time we talked about this, the reasoning was that we wanted to
eventually get rid of consumer-side auto-topic creation ent
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.
ics that get put on the "bad" replica.
Perhaps we should reopen the discussion about
https://cwiki.apache.org/confluence/display/KAFKA/KIP-201%3A+Rationalising+Policy+interfaces
regards,
Colin
>
> Please let me know there are more question.
>
>
> Thanks,
> George
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
oducing?
I was thinking about a PlacementPolicy filling the role of preventing people
from creating single-replica partitions on a node that we didn't want to ever
be the leader. I thought that it could also prevent people from designating
those nodes as preferred leaders during topic creat
> -Original Message-----
> From: Colin McCabe
> Sent: Wednesday, August 7, 2019 5:17 PM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-455: Create an Administrative API for Replica
> Reassignment
>
> On Wed, Aug 7, 2019, at 15:41, George Li wrote:
> > T
Hi Rajini,
Thanks for the KIP. This will be a great improvement.
Why not just pass the cluster ID directly to Authorizer#start, rather than
dealing with the ClusterResourceListener interface? That seems like it would
be simpler. If authorizers don't need that information, they can ignore 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, 2019, at 14
Harsha made a good point that you can achieve your goals through KIP-492.
Security configuration is starting to get pretty complex-- is there a reason
not to use the existing configurations?
Also, it seems like most people who want a custom truststore / keystore will
also want a custom SSL pro
this
> something we should keep?
>
> Thanks
>
> On Mon, Aug 5, 2019 at 7:44 PM Colin McCabe wrote:
> >
> > On Mon, Aug 5, 2019, at 10:02, Tom Bentley wrote:
> > > Hi Colin,
> > >
> > > Thanks for the KIP.
> > >
> > > Curren
ndamental disagreement in what we
> > should
> > > allow the producer to do.
> > > In my previous message I mentioned a config that would allow for the
> > broker
> > > to prevent producer auto-creation. (It would be disabled by default.) It
> > &g
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:23
+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 12:50 PM, Dongjin Lee wrote:
>
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,
Hi,
If there’s no need to consume records in the Spark driver, then the Consumer is
probably the wrong thing to use. Instead, Spark should use AdminClient to find
out what partitions exist and where, manage their offsets, and so on. There are
some KIPs under discussion now that would add the ne
Hi Michael,
The NetworkClient periodically fetches metadata so that it always knows what
the cluster topology is. This also helps it to have some open connections when
needed to reduce the latency of operations.
To be fair, we haven’t thought very much about optimizing this since the
overhead
+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
> > feature release (v2.4.0).
> >
> > If tha
+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
> (CreateTokens on Clust
rn against the list
> > of available topics in the driver.
> >
> > As you use `assignment()` and store offsets in the Spark checkpoint, it
> > seems that using consumer group management is not a good fit for the use
> > case.
> >
> >
> > Thoughts?
> >
ir point. It would be shorter on average, but worse for some
exceptional cases. Also, the decoding would be more complex, which might be a
good reason to go for just having two varints. Yeah, let’s simplify.
Regards,
Colin
>
> Thanks,
> Jason
>
>
> On Fri, Aug 9, 2019 at 4:31 PM
this as it is until KIP-396 passes the vote (the vote
> >> for KIP-396 opened at January and it still doesn't pass - 7 months - which
> >> worries me a bit if it's going to pass the vote or not), but I also
> >> respect
> >> the lifecycle of KIP in Ka
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, 2019 at 11:18 AM
Hi Mickael,
Considering that KIP-496, which adds a way of deleting consumer offsets from
AdminClient, looks like it is going to get in, this seems like functionality we
should definitely have.
For alterConsumerGroupOffsets, is the intention to ignore partitions that are
not specified in the ma
Hi Rajini,
I think it would be good to rename KafkaRequestContext to something like
AuthorizableRequestContext, and put it in the
org.apache.kafka.server.authorizer namespace. If we put it in the
org.apache.kafka.common namespace, then it's not really clear that it's part of
the Authorizer AP
quot;
> > > to
> > > > >
> > > > > *KafkaFuture>>*
> > > > >
> > > > > This is because we will have a hierarchy of two-layers of errors
> > since
> > > we
> > > > > need to find out
Has anyone considered a scheme for sharding topic data across multiple
disks?
For example, if you sharded topics across 3 disks, and you had 10 disks,
you could pick a different set of 3 disks for each topic. If you
distribute them randomly then you have 10 choose 3 = 120 different
combinations.
workClient's exponential backoff ?
> It seems the NetworkClient has no exponential backoff (the
> reconnect.backoff.ms parameter)
>
>
> Thanks
> David
>
>
>
>
> -- 原始邮件 --
> 发件人: "Colin McCabe";;
> 发送时间: 2017年5月31日
he behaviour
> consistent across broker versions is the better option, so the PR was
> updated to do that.
>
> Ismael
>
> On Mon, May 22, 2017 at 7:42 PM, Colin McCabe wrote:
>
> > > As you noted, though, we don't have a way to do this for the 0.10.x
> > > re
Hi all,
I posted "KIP-180: Add a broker metric specifying the number of consumer
group rebalances in progress" for discussion:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-180%3A+Add+a+broker+metric+specifying+the+number+of+consumer+group+rebalances+in+progress
Check it out.
cheers,
Co
uld be sufficient for alerting. And trouble shooting
> > of
> > > the issue could be relying on the log4j.
> > >
> > > *Guozhang*
> > >
> > > On Fri, Jul 21, 2017 at 7:19 AM, Ismael Juma wrote:
> > >
> > > > Thanks for th
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
>
>
>
sure if that's better.
> >
> > Ismael
> >
> > On Mon, Jul 24, 2017 at 7:02 PM, Guozhang Wang wrote:
> >
> > > Actually Rebalancing includes two steps, and we name them
> > PrepareRebalance
> > > and WaitSync (arguably they may not
e terms? For example: RebalanceJoin and
> > > > RebalanceAssignment. What do you think?
> > > >
> > > > -Jason
> > > >
> > > > On Fri, Jul 28, 2017 at 11:18 AM, Guozhang Wang
> > > > wrote:
> > > >
> > > &g
t; Apurva
>
> On Mon, Aug 7, 2017 at 5:09 PM, Colin McCabe wrote:
>
> > How about PreparingRebalance / CompletingRebalance?
> >
> > cheers,
> > Colin
> >
> >
> > On Fri, Aug 4, 2017, at 09:03, Ismael Juma wrote:
> > > I agree that we shoul
Hi all,
I think it's a good time to vote on KIP-180. It adds a helpful new
metric that shows consumer group states.
The full proposal, and links to more discussion, are here:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-180%3A+Add+a+broker+metric+specifying+the+number+of+consumer+group+
> wrote:
>
> > +1. Thanks.
> >
> > On Sat, Aug 12, 2017 at 11:18 AM, Ismael Juma wrote:
> >
> > > Thanks for the KIP, +1 (binding). Seems like the KIP title has to be
> > > updated still.
> > >
> > > Ismael
> > >
&
Hi all,
I've been working on a fault injector for Apache Kafka. The general
idea is to create faults such as network partitions or disk failures,
and see what happens in the cluster. The fault injector can run as part
of a ducktape system test, or standalone.
The fault injector has two processe
Hi,
Thanks for the KIP. It looks good overall.
On Tue, Aug 22, 2017, at 08:54, Tom Bentley wrote:
> Hi Jun,
>
> Thanks for the feedback.
>
> I've updated the KIP to mention this new algorithm, which I agree will be
> much better from the AdminClient PoV.
>
> I've also reverted the authorizati
Hmm. There are a lot of configuration keys that involve "log cleaner."
It seems like if we rename this component, logically we'd have to rename
all of them and support the old versions as deprecated config keys:
val LogCleanupPolicyProp = "log.cleanup.policy"
val LogCleanerThreadsProp = "log
401 - 500 of 1864 matches
Mail list logo
