gt; > > is partitioned from the controller
> > >
> > > << > > >>>Eventually, the active controller will ask the broker to finally go
> > > offline
> > >
> > > << > > the controller
> > > >>>New versi
rectly to
> > the active controller
> >
> > << > instead
> > >>>In the post-ZK world, the leader will make an RPC to the active
> > controller instead
> >
> > << > controller.
> > >>>For example, the brokers may ne
K world, the leader will make an RPC to the active
> controller instead
>
> << controller.
> >>>For example, the brokers may need to forward their requests to the
> active controller.
>
> << registrations
> >>>The new (active) controller will m
g)?
>
> Ryanne
>
> On Wed, Aug 21, 2019, 1:28 PM Colin McCabe wrote:
>
> > On Wed, Aug 21, 2019, at 06:38, Eno Thereska wrote:
> > > Hi Colin,
> > >
> > > Nice KIP! For such a big change it would be good to add a pointer or
> > > two to
I think it's worth considering separating out the permissions needed to create
a consumer group from the permissions needed to join one. We distinguish these
permissions for topics, and people generally find it useful. We could start
checking CREATE on GROUP, perhaps? It might be hard to do
s release. I added
some more descriptive text to the bridge release paragraph-- hopefully this
makes it clearer.
best,
Colin
>
> Do I understand it correctly, and might some change in phrasing or
> additional clarification help others avoid the same confusion I had?
>
> Ron
>
out the specific details.
best,
Colin
>
> On Thu, Aug 22, 2019, 11:58 AM Colin McCabe wrote:
>
> > On Wed, Aug 21, 2019, at 19:48, Ron Dagostino wrote:
> > > Thanks, Colin. The changes you made to the KIP related to the bridge
> > > release help make it clear
+1 (binding).
cheers,
Colin
On Tue, Aug 20, 2019, at 10:55, Jason Gustafson wrote:
> Hi All,
>
> I'd like to start a vote on KIP-352, which is a follow-up to KIP-455 to
> fix
> a long-known shortcoming of URP reporting and to improve reassignment
> monitoring:
> https://cwiki.apache.org/conflue
URPs based on
that. +1 for this. (I assume Jason will update the KIP...)
best,
Colin
>
> Taking that into account, +1 from me! (non-binding)
>
> On Fri, Aug 23, 2019 at 7:00 PM Colin McCabe wrote:
>
> > +1 (binding).
> >
> > cheers,
> > Colin
> >
o nail down what we are voting for.
>
> Ryanne
>
>
> On Fri, Aug 23, 2019, 12:58 PM Colin McCabe wrote:
>
> > On Fri, Aug 23, 2019, at 06:24, Ryanne Dolan wrote:
> > > Colin, can you outline what specifically would be in scope for this KIP
> > vs
> &g
t is important enough to be in the spec
> file, it should be in
> a proper JSON field (e.g., about), which makes sure it ends up in the
> generated protocol docs instead of being filtered out.
>
Yeah, we could consider reorganizing this a bit. This seems like a separate
issue fr
Hi all,
After some discussion with Jun and Stan, we decided that we should bump the
version of the topics znode from 1 to 2. The bump is backwards compatible
(older brokers can read the v2 znode). I have updated the KIP.
best,
Colin
On Thu, Aug 8, 2019, at 11:09, Colin McCabe wrote:
>
On Fri, Aug 23, 2019, at 00:07, Magnus Edenhill wrote:
> Great proposal, this feature is well overdue!
>
> 1)
> From an operator's perspective I don't think the kafka client
> implementation name and version are sufficient,
> I also believe the application name and version are of interest.
> You c
On Thu, Aug 29, 2019, at 09:27, Pere Urbón Bayes wrote:
> Thanks,
> yes I know the KIP-500, how realistic is to have it landing for 2.4? if
> not really, end of the day we will need something like KAFKA-8843 for this
> version.
>
> Looking forward to help out.
>
Hi Pere,
Thanks for contributi
On Mon, Aug 26, 2019, at 14:03, Jason Gustafson wrote:
> Hi Arjun,
>
> From a high level, I feel like we are making light of the JMX api because
> it's convenient and the broker already has it. Personally I would take the
> broker out of the picture. The JMX endpoint is not something we were happy
As Gwen commented earlier, the client already has the record that it sent,
including all the headers.
>
> Future future = producer.send(myRecord, null);
> future.get();
> System.out.println("I sent myRecord with headers " + myRecord.headers());
>
best,
Colin
On Tue, Aug 27, 2019, at 17:06, Ren
Hi Pere,
It will depend on how quickly the KIP can be voted in, and then implemented.
Manikumar Reddy is going to be the release manager for Apache Kafka 2.4.0.
Right now, the KIP freeze is scheduled for Sep 25, 2019. A KIP must be
accepted by this date in order to be part of 2.4.0. (Being a
gt;> > > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > Hi Colin
> > >> > > >
> > >> > > > When I refer to "standard" or "custom" algorithms I am following
> >
faces will be "file based" loading vs
> > if somebody wants to customize any of it they can.
> >
> > Would that make sense?
> >
> > On Fri, Aug 30, 2019 at 10:03 AM Colin McCabe wrote:
> >
> >> +1 for making SslEngineBuilder configurable. This would
es.
This is something that we'll discuss when people propose release schedules. In
general, this isn't fundamentally different than someone wanting a new release
of 1.x because they don't want to upgrade to 2.x. If there's enough interest,
we'll do it.
best,
Colin
&g
take up that work for making it configurable.
> > >
> > > Thanks
> > > Maulin
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Aug 30, 2019 at 10:34 AM Maulin Vasavada <
> > > maulin.vasav...@gmail.com>
> &
Hi all,
I'd like to start the vote for KIP-482: The Kafka Protocol should Support
Optional Tagged Fields.
KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-482%3A+The+Kafka+Protocol+should+Support+Optional+Tagged+Fields
Discussion thread here:
https://lists.apache.org/thread.html/cdc
> retain the
> > > old
> > > authorizer as-is. SimpleAclAuthorizer will continue to
> > implement the
> > > old
> > > API, but will be deprecated. A new authorizer implementation
> > > kafka.security.authoriz
sues, I think we should come up
> > with a minimal validation and ensure it won't become more restrictive in
> > the future.
> >
> > 4. I don't have strong opinion regarding this one but as the focus of the
> > KIP is to gather the client's information, I
tion
via HTTPS, for example. Or maybe they want to use a native library of some
kind. And so on.
best,
Colin
>
> With this - open to all the suggestions and further improvements.
>
> Thanks
> Maulin
>
>
> On Tue, Sep 3, 2019 at 10:07 AM Colin McCabe wrote
mando Garcia Sancio
> > > > wrote:
> > > >
> > > > +1 (non-binding)
> > > >
> > > > Looking forward to this improvement.
> > > >
> > > > On Tue, Sep 3, 2019 at 12:49 PM David Jacot
> > wrote:
>
> > actions);
> > >> > > > > > List>
> > >> > > > > > createAcls(AuthorizableRequestContext requestContext,
> > >> > > > > List
> > >> > > > > > aclBindings);
&g
hink single-replica partition might not be a good example. There
> should not be any single-replica partition at all. If yes. it's
> probably because of trying to save disk space with less replicas. I
> think at least minimum 2. The user purposely creating single-replica
> pa
Hi Maulin,
Clement brought up a good point, which is that we should have agreement on the
overall design before we start looking at PRs. In Kafka, that means starting a
discussion on a KIP, and then getting that KIP voted in.
There is more information about the KIP process here:
https://cwiki.
Sorry, I meant to write "removing an API typically requires a new major release
of Kafka". Deprecating an API can be done in a minor release.
regards,
Colin
On Fri, Sep 6, 2019, at 14:49, Colin McCabe wrote:
> Hi Maulin,
>
> Clement brought up a good point, which is
,
Colin
On Fri, Sep 6, 2019, at 13:36, Jason Gustafson wrote:
> +1 Thanks Colin. This is really going to help with compatibility.
>
> -Jason
>
> On Wed, Sep 4, 2019 at 1:34 PM Colin McCabe wrote:
>
> > On Wed, Sep 4, 2019, at 13:01, Jason Gustafson wrote:
> > > Hi
know the version used,
> we have two options: 1) use version 0 which is a prefix of all others but
> it means losing information; or 2) try versions in descending order from N
> to 0. I guess that N-1 would the one in most of the cases.
>
> What is your opinion regarding the client s
ist broker_ids), and easier to
> > update/remove, no need for external json files?
> >
> >
> > Thanks,
> > George
> >
> > On Friday, September 6, 2019, 02:20:33 PM PDT, Colin McCabe <
> > cmcc...@apache.org> wrote:
> >
> > One pos
Hi all,
I'd like to start the vote for KIP-500: Replace ZooKeeper with a Self-Managed
Metadata Quorum.
The DISCUSS thread from the mailing list is here:
https://lists.apache.org/thread.html/cce5313ebe72bde34bf0da3af5a1723db3ee871667b1fd8edf2ee7ab@%3Cdev.kafka.apache.org%3E
The KIP is here:
http
nd. Why do we think
> > this has to happen before authenticating?
> >
> > It sounds like addition another protocol will allow us to keep the
> > special assumptions around ApiVersionsRequest and will remove the
> > dependency on KIP-482. Which will make KIP-511 much simpler than the
Hi Ash,
At first guess, you probably had a problem with your log cleaner thread, which
resulted in the offsets log not being cleaned. Check if that thread is running.
best,
Colin
On Wed, Sep 11, 2019, at 09:52, Ash G wrote:
> Bump, no reply,
>
> It seems this condition was missed by devs when
Hi Radai,
Thanks for the KIP. Sounds interesting. I assume that if an
InterruptedException were caught, that would be rethrown, rather than returning
false? It might be good to specify that. Can you give an example of how this
would be used?
best,
Colin
On Thu, Sep 12, 2019, at 15:26, ra
Hi Lucas,
Thanks for tackling this. Topic IDs are a great idea, and this is a really
good writeup.
For /brokers/topics/[topic], the schema version should be bumped to version 3,
rather than 2. KIP-455 bumped the version of this znode to 2 already :)
Given that we're going to be seeing these
; }
> ]
> }
> ]
> }
>
> I would like to know if there are any concerns or objections regarding this
> change before updating the KIP.
>
> Best,
> David
>
> On Wed, Sep 4, 2019 at 9:24 AM David Jacot wrote:
>
> > Hi all
!
> > >
> > > +1 (binding)
> > >
> > > -Bill
> > >
> > > On Thu, Sep 12, 2019 at 3:26 PM Ismael Juma wrote:
> > >
> > > > Thanks for the KIP, +1 (binding).
> > > >
> > > > Ismael
> > >
Hi David,
Thanks for the KIP!
Nitpick: in the intro paragraph, "Operators of Apache Kafka clusters have
literally no information about the clients connected to their clusters" seems a
bit too strong. We have some information, right? For example, the client ID,
where clients are connecting fr
describe, --delete,
> --reset-offsets
Did you mean to add a new action here that was offsets-related?
best,
Colin
>
> What do you think?
>
> Best,
> David
>
>
> On Fri, Sep 13, 2019 at 6:42 PM Colin McCabe wrote:
>
> > Hi David,
> >
> > Sounds
Hi Mickael,
Just to give you the context, this is something that's been discussed several
times.
Check out https://issues.apache.org/jira/browse/KAFKA-5214 and
https://issues.apache.org/jira/browse/KAFKA-5723 , as well as this pull
request: https://github.com/apache/kafka/pull/3012
I think th
gest we return an ApiVersionResponse with an error code and a
> human-readable error message field.
>
>
>
> Den ons 18 sep. 2019 kl 20:05 skrev Colin McCabe :
>
> > Hi David,
> >
> > Thanks for the KIP!
> >
> > Nitpick: in the intro paragraph, &qu
Hi Rajini,
Thanks for the KIP. I think this will be a great improvement.
For NumPartitions, ReplicationFactor, and Configs, we need some reasonable
default value in the RPC which can be used for requests that are too old to
contain this information. I'd suggest 0, 0, and null, respectively.
cas,
etc. is not usually considered a topic configuration (although I guess
philosophically it is...). Usually "topic configuration" means the key/value
pairs, right?
best,
Colin
>
> Thank you,
>
> Rajini
>
> On Wed, Sep 18, 2019 at 9:23 PM Colin McCabe wrote:
>
gt;
> > I'm not sure if we want to add an error string field just for this
> > (although they're a good idea in general...)
> >
> > best,
> > Colin
> >
> > On Wed, Sep 18, 2019, at 12:31, Magnus Edenhill wrote:
> > > > I think we should
Rajini
>
> On Thu, Sep 19, 2019 at 5:22 PM Colin McCabe wrote:
>
> > On Thu, Sep 19, 2019, at 06:31, Rajini Sivaram wrote:
> > > Hi Colin,
> > >
> > > Thanks for reviewing the KIP!
> > >
> > > I have added default values for the RPC. Sinc
sumer-groups.sh --bootstrap-server
> —delete-offsets --group --topic :
> ex: --bootstrap-server localhost:9092 --group my-group --topic
> topic1 --topic topic2:0,1,2
>
> When partitions is not provided, all partitions are used.
>
> Best,
> David
>
> Le mer.
wse/KAFKA-8584
> > pr - https://github.com/apache/kafka/pull/7342
> >
> > and one from Colin McCabe:
> >
> > KAFKA-8628: Auto-generated Kafka RPC code should be able to use zero-copy
> > ByteBuffers
> > ticket - https://issues.apache.org/jira/browse/KAFKA
Hi Tom,
As you said, there were a few KIPs, but they seem to have become inactive.
It's kind of a tough problem-- probably at least as complex as the admin
interface for ACLs.
There's also the headache of how reassignment quotas should work. We probably
want to change that quota to actually t
onses based on the length of the response. We should add
this detail to the KIP.
+1 (binding) after that change.
cheers,
Colin
>
> > Agreed. This is a good use-case for INVALID_REQUEST. We should add a
> comment that this is now a valid error.
>
> I have documented the erro
+1 (binding). Thanks, Rajini.
best,
Colin
On Fri, Sep 20, 2019, at 00:43, Rajini Sivaram wrote:
> Hi all,
>
> I would like to start vote on KIP-525 to return configs in CreateTopics
> response. This is a minor KIP that returns additional data in the response
> without breaking compatibility.
>
alterConfigs) is one of the cases which would
> benefit from this API. So I'm not sure I fully agree with the concerns
> expressed. The reasons we added the BrokerApiVersionsCommand tool a
> while back must also still be valid. What do you think?
>
> Thanks
>
> On Wed
without it.
best,
Colin
>
> Jun
>
>
>
>
> On Fri, Sep 6, 2019 at 3:06 PM Colin McCabe wrote:
>
> > Hi all,
> >
> > The KIP-482 vote has passed. Thanks to everyone who voted or discussed
> > the issue.
> >
> > There were 3 non-binding
Looks good. +1 (binding)
best,
Colin
On Tue, Sep 24, 2019, at 09:42, Jason Gustafson wrote:
> Hi All,
>
> I'm starting a vote for KIP-524, which is a small change to the config
> tool:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-524%3A+Allow+users+to+choose+config+source+when+descri
On Sat, Sep 28, 2019, at 17:49, Magnus Edenhill wrote:
> Den mån 23 sep. 2019 kl 14:42 skrev Colin McCabe :
>
> > On Fri, Sep 20, 2019, at 18:05, Jun Rao wrote:
> > > 101. We already use varInt in the message format. I assume that the
> > > protocol uses the same var
#x27;ve been working on a KIP
> > about reworking replication throttling to introduce reassignment throttling
> > so perhaps it would make to discuss them somewhat together. I'll try to
> > publish it soon but not sure I can until after the summit.
> >
> > Vikto
ustafson
> > wrote:
> >
> > > Thanks Stan, good catch. I have updated the KIP. I will plan to close the
> > > vote Monday if there are no objections.
> > >
> > > -Jason
> > >
> > > On Fri, Aug 23, 2019 at 11:14 AM Colin McCabe
&g
) but not underMinIsr,
> > as
> > > >> we
> > > >> > have an ISR of 3.
> > > >> > Technically, any produce requests with acks=all would succeed, so it
> > > >> would
> > > >> > be false to report `underMinIsr
Hi all,
I wrote a short KIP about adding a metric to track the number of open
connections with a given SSL cipher type. Take a look here:
https://cwiki.apache.org/confluence/x/txPjBw
best,
Colin
>
> > Please, review my changes [1]
> > I fixed all conflicts after KAFKA-8885 [2] merge [3].
> >
> > [1] https://github.com/apache/kafka/pull/7342
> > [2] https://issues.apache.org/jira/browse/KAFKA-8885
> > [3]
> > https://github.com/apache/kafka/
}
> > >}
> > > }
> > >
> > > an unbounded flush could cause the consumer to be considered dead and
> > > send the whole app into rebalance storms, so we'd really love to be
> > > able to put a time bound on it.
> > >
> > >
On Mon, Oct 21, 2019, at 03:59, Viktor Somogyi-Vass wrote:
> Hey Tom,
>
> Bringing over the conversation from KIP-500 and also adding my
> observations. Let me capture them in points.
>
> 1. Perhaps I'm a bit aggressive in introducing new features but I'm not
> sure if we need sasl.scram.password
Hi Jason,
Thanks for the KIP. I think this is a long-overdue improvement.
It would be good to clarify that the "timeout" values for the options classes
will now refer to the API timeouts, not to the request timeouts. I think this
is implied by the KIP, but it would be good to spell it out.
O
Hi all,
I wrote a KIP about creating a fetch.max.bytes configuration for the broker.
Please take a look here: https://cwiki.apache.org/confluence/x/4g73Bw
thanks,
Colin
Hi all,
I'd like to start the vote on KIP-538: Add a metric tracking the number of open
connections with a given SSL cipher type.
KIP: https://cwiki.apache.org/confluence/x/txPjBw
Discussion thread:
https://lists.apache.org/thread.html/b1ee845ef3a3d4fe4d83da81d5444cf00e43840d3b2710487255e6eb@%
something simpler and just allow the creation if at
> > least min-in-sync replicas are available? That should not require
> > changes to the protocol and while this might not cover all possible
> > use cases, that would still cover the use cases we've listed in the
> > KI
ster's disks are, and other factors.
best,
Colin
>
> On Mon, 21 Oct 2019 at 22:57, Colin McCabe wrote:
>
> > Hi all,
> >
> > I wrote a KIP about creating a fetch.max.bytes configuration for the
> > broker. Please take a look here:
> > https://cwiki.apache.org/confluence/x/4g73Bw
> >
> > thanks,
> > Colin
> >
>
+1 (binding).
Thanks, Jason.
best,
Colin
On Mon, Oct 21, 2019, at 17:27, Jason Gustafson wrote:
> I'd like to start a vote for KIP-537:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-537%3A+Increase+default+zookeeper+session+timeout
> .
>
> +1 from me
>
> Thanks,
> Jason
>
Hi Brian,
Thanks for the KIP! This looks like a nice cleanup. It will be good to be
able to perform these operations without direct ZK access.
I guess this is a nitpick, but for the operations proposed for later, it might
be nice to have a different color, like yellow, to indicate that we'll
>
> > On Tue, Oct 22, 2019 at 12:42 AM Tom Bentley wrote:
> >
> > > +1 (non-binding). Thanks!
> > >
> > > On Tue, Oct 22, 2019 at 1:03 AM Gwen Shapira wrote:
> > >
> > > > +1
> > > >
> > > > T
+ dev@kafka.apache.org
On Tue, Oct 22, 2019, at 15:48, Colin McCabe wrote:
> +1. I ran the broker, producer, consumer, etc.
>
> best,
> Colin
>
> On Tue, Oct 22, 2019, at 13:32, Guozhang Wang wrote:
> > +1. I've ran the quick start and unit tests.
> >
> &
Hi Ismael,
That's a good idea! I added it to the KIP.
best,
Colin
On Wed, Oct 23, 2019, at 12:59, Ismael Juma wrote:
> Hi Colin,
>
> Thanks for the KIP. Would it make sense to have a tag with the TLS version
> as well?
>
> Ismael
>
> On Mon, Oct 21, 2019 a
Hi all,
With 5 binding +1 votes from Gwen Shapira, Jason Gustafson, Colin McCabe,
Ismael Juma, Rajini Sivaram, and 2 non-binding +1 votes from Tom Bentley and M.
Manna, the vote passes. Thanks, all.
best,
Colin
On Thu, Oct 24, 2019, at 08:32, Rajini Sivaram wrote:
> +1 (binding)
>
&g
gt; >
> > > > Also, would you kindly suggest how (or if ) the traditional performance
> > > > tests are affected due to this change?
> > > > Regards,
> > > >
> > >
> > > There shouldn't be any effect at all, since the
onsider something
> like 55 MB, which is 10% above the default for consumers?
>
> Ismael
>
> On Mon, Oct 21, 2019 at 2:57 PM Colin McCabe wrote:
>
> > Hi all,
> >
> > I wrote a KIP about creating a fetch.max.bytes configuration for the
> > broker. Please
Hi all,
I'd like to start the vote on KIP-541: Create a fetch.max.bytes configuration
for the broker.
KIP: https://cwiki.apache.org/confluence/x/4g73Bw
Discussion thread:
https://lists.apache.org/thread.html/9d9dde93a07e1f1fc8d9f182f94f4bda9d016c5e9f3c8541cdc6f53b@%3Cdev.kafka.apache.org%3E
c
Hi Vikto,
That's an interesting idea. However, I think it's better to consider it
outside the context of this KIP. I think one-letter abbreviations would be
controversial, and aren't really related to fixing the ZK dependency here.
+1 (binding). Thanks, Brian.
best,
Colin
On Thu, Oct 31,
Sorry, that should read "Hi Viktor",-C.
On Thu, Oct 31, 2019, at 14:08, Colin McCabe wrote:
> Hi Vikto,
>
> That's an interesting idea. However, I think it's better to consider
> it outside the context of this KIP. I think one-letter abbreviations
>
>
> > -David
> >
> > On Fri, Oct 25, 2019 at 4:33 AM Tom Bentley wrote:
> >
> > > +1 nb. Thanks!
> > >
> > > On Fri, Oct 25, 2019 at 7:43 AM Ismael Juma wrote:
> > >
> > > > +1 (binding)
> > > >
> > > >
Hi all,
With binding +1 votes from Ismael Juma, David Arthur, and Colin McCabe, and
non-binding +1 votes from Tom Bentley and Stanislav Kozlovski, the vote passes.
thanks, all.
Colin
On Fri, Nov 1, 2019, at 09:41, Colin McCabe wrote:
> I will add my +1, binding
>
> best,
> Colin
Hi Brian,
Thanks for the KIP. +1 (binding).
best,
Colin
On Thu, Nov 7, 2019, at 08:41, Brian Byrne wrote:
> Hello all,
>
> Ping. Any further votes or opinions?
>
> Thanks,
> Brian
>
> On Tue, Oct 29, 2019 at 9:39 AM Brian Byrne wrote:
>
> > Hello all,
> >
> > I'd like to call a vote on KI
Hi Brian,
Thanks for the KIP.
Starting the metadata fetch before we need the result is definitely a great
idea. This way, the metadata fetch can be done in parallel with all the other
stuff e producer is doing, rather than forcing the producer to periodically
come to a halt periodically while
:35 AM Mickael Maison
> wrote:
> >
> > Hi,
> >
> > Thanks Colin for the feedback. Edo and I have updated the KIP
> > accordingly. Can you take another look?
> >
> >
> > On Tue, Oct 22, 2019 at 12:20 AM Colin McCabe wrote:
> > >
> > &g
should
do. So I think that the error code should actually be a little bit more
specific, or at least tell the end user what to do with it (that's why I
suggested "busy").
>
> Voilà. I hope that I have addressed all your questions/points and I am
> sorry for the lengthy emai
gt; >> We added a new quota name in the KIP. You chose not to bump up the version
> >> of DESCRIBE_CLIENT_QUOTAS and ALTER_CLIENT_QUOTAS, which seems ok since
> >> the
> >> quota name is represented as a string. However, the new quota name can be
> >>
HI Vinicius,
This question seems like a better fit for the user mailing list rather than the
developer mailing list.
Anyway, if I understand correctly, you are asking if the producer can choose to
assign partitions in a round-robin fashion rather than based on the key. The
answer is, you can,
Hi Boyang,
Thanks for the KIP! I think it's getting close.
> For older requests that need redirection, forwarding
> broker will just use its own authorizer to verify the principals. When the
> request looks good, it will just forward the request with its own
> credentials, no second valid
Hi Tom,
It's an interesting idea. Obviously protocol buffers does this for all numeric
fields.
I have to admit I have some mixed feelings, since this is another thing that
makes encoding more complex. And it's not a clear win in all cases, although
it is in some.
I assume that the performan
there is currently no way to do partition balancing on the
> broker - the producer sends messages directly to partition leaders so
> partition currently needs to be defined on the producer.
>
> I understand that in order to perform round robin across partitions of a
> topic when working w
Hi Cheng,
The link from the main KIP page is an "edit link" meaning that it drops you
into the editor for the wiki page. I think the link you meant to use is a
"view link" that will just take you to view the page.
In general I'm not sure what I'm supposed to take away from the large UML
diagr
On Fri, Jun 12, 2020, at 15:30, Boyang Chen wrote:
> Thanks Colin for the suggestions!
>
> On Fri, Jun 12, 2020 at 2:40 PM Colin McCabe wrote:
>
> > Hi Boyang,
> >
> > Thanks for the KIP! I think it's getting close.
> >
> > > For older reques
gt; of the key) to decide the partition.
> We noticed enqueuing and timeouts while several consumers were idle - which
> made us take a better look on how the load is balanced.
>
> I believe the only way to perform equal load balance without having to know
> other producers would be to do
Hi Sam,
Thanks for the KIP.
Can you add some text clarifying whether a done task continues to be counted in
the created-task-count?
Looks good aside from that.
best,
Colin
On Wed, Jun 17, 2020, at 12:31, Sam Pal wrote:
> Hi all,
>
> I’d like to start a discussion about adding metrics to Tr
Thanks, Boyang! +1 (binding)
best,
Colin
On Mon, Jun 15, 2020, at 12:59, Boyang Chen wrote:
> Thanks for more feedback Colin! I have addressed them in the KIP.
>
> Boyang
>
> On Mon, Jun 15, 2020 at 11:29 AM Colin McCabe wrote:
>
> > On Fri, Jun 12, 2020, at
; > On Thu, Jun 18, 2020 at 12:00 AM Jose Garcia Sancio <
> > > jsan...@confluent.io>
> > > > wrote:
> > > >
> > > > > +1.
> > > > >
> > > > > Thanks for the KIP and looking forward to the improvement
> > > imple
On Tue, Jun 16, 2020, at 07:42, Tom Bentley wrote:
> Hi Colin,
>
> Thanks for taking a look at it. Replies inline...
>
> On Mon, Jun 15, 2020 at 6:22 PM Colin McCabe wrote:
>
> > Hi Tom,
> >
> > It's an interesting idea. Obviously protocol buf
Congratulations, Boyang!
cheers,
Colin
On Mon, Jun 22, 2020, at 16:26, Guozhang Wang wrote:
> The PMC for Apache Kafka has invited Boyang Chen as a committer and we are
> pleased to announce that he has accepted!
>
> Boyang has been active in the Kafka community more than two years ago.
> Since
> > > On Fri, Jun 19, 2020 at 3:18 PM Ismael Juma wrote:
> > >
> > > > Hi Colin,
> > > >
> > > > The KIP states in the Compatibility section (not Future work):
> > > >
> > > > "To support the proxy of requests, we need to build a channel for
> > > > brokers to talk directly to the controller. This
601 - 700 of 1863 matches
Mail list logo
