Given that we already have
`transaction.abort.timed.out.transaction.cleanup.interval.ms` and
`transaction.remove.expired.transaction.cleanup.interval.ms`, it seems
OK to add another one for our case here. Regarding the name, I would
follow the pattern that we use for those two existing configs. We
[
https://issues.apache.org/jira/browse/KAFKA-14148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-14148.
-
Fix Version/s: 3.3.0
Resolution: Fixed
> Outdated doc for reset-offsets opt
week.
>
> Best,
> Stanislav
>
> On Tue, Aug 9, 2022 at 5:06 AM David Jacot
> wrote:
>
> > Throwing an UnsupportedVersionException with an appropriate message
> > seems to be the best option when the new API is not supported and
> > AllowReplicationFactorCh
n I thought connect can also
> > fit
> > > >> into
> > > >> > this new scheme is that even today the connect uses a
> > > WorkerCoordinator
> > > >> > extending from AbstractCoordinator to empower rebalances of
> > > &
Hi Yash,
You are all set.
Best,
David
On Thu, Aug 11, 2022 at 3:47 PM Yash Mayya wrote:
>
> Hey folks,
>
> I can't currently assign Apache Kafka Jiras to myself and I just discovered
> that someone needs to add me to the contributors list in order for me to be
> able to do that. Could someone p
[
https://issues.apache.org/jira/browse/KAFKA-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-14140.
-
Resolution: Fixed
> Ensure an offline or in-controlled-shutdown replica is not eligible to j
That's a great idea. I am +1 as well.
Thanks,
David
On Tue, Aug 9, 2022 at 11:54 PM Guozhang Wang wrote:
>
> +1 as well. I think adding such proofs in the repo could encourage more
> people reviewing and challenging it, helping to improve whenever we see
> fit. Also it helps readers better under
data() method by plumbing into
> > >> JoinGroupRequestProtocol.
> > >> >
> > >> > I think the changes to support connect would be similar at a high
> > level
> > >> to
> > >> > the changes in streams mainly because of the Cli
;, right?
>
> 6. In "ConsumerGroupDescribe API" section:
> When the group coordinator handle a ConsumerGroupPrepareAssignmentRequest
> request:
> -> It should be "handle a ConsumerGroupDescribe request"
Thanks for reporting the typos. I will fix them.
Best,
David
it here for now in order to
ensure that this KIP is compatible with what we will do for Connect in
the future.
Best,
David
On Mon, Aug 8, 2022 at 2:41 PM David Jacot wrote:
>
> Hi all,
>
> I am back from vacation. I will go through and address your comments
> in the coming
Throwing an UnsupportedVersionException with an appropriate message
seems to be the best option when the new API is not supported and
AllowReplicationFactorChange is not set to the default value.
Cheers,
David
On Mon, Aug 8, 2022 at 6:25 PM Vikas Singh wrote:
>
> I personally like the UVE option
Thanks for the KIP, Justine. The proposal makes sense to me. I am +1 (binding).
Cheers,
David
On Mon, Aug 8, 2022 at 6:18 PM Justine Olshan
wrote:
>
> Hi all,
> I'd like to start a vote for KIP-854: Separate configuration for producer
> ID expiry.
>
> KIP:
> https://cwiki.apache.org/confluence/d
changes to support connect would be similar at a high
> > level
> > >> to
> > >> > the changes in streams mainly because of the Client side assignors
> > being
> > >> > used in both. At an implementation level, we might need to make a lot
> > of
> > >> >
I'll be away from July 18th to August 8th with limited access to my
emails so I will address new comments and questions when I come back.
Cheers,
David
On Fri, Jul 15, 2022 at 2:16 PM David Jacot wrote:
>
> Hi Sagar,
>
> Thanks for your comments.
>
> 1) Yes. That refe
see this in a lot of other places, so have I understood it incorrectly ?
>
>
> Regarding connect , it might be out of scope of this discussion, but from
> what I understood it would probably be running in client side assignor mode
> even on the new rebalance protocol as it has i
blem is the same because the configs
are also automatically deleted. Things would be different if groups
were a first class resource in the cluster.
Best,
David
On Fri, Jul 15, 2022 at 1:30 PM David Jacot wrote:
>
> Thanks Hector! Our goal is to move forward with specialized API
> i
lized in the metadata log for various
> reasons (auditability, visibility, consistency, etc.). Similarly, I am not
> sure about automatically deleting configs in a way that they cannot be
> recovered. A good property for modern systems is to minimize the number of
> unrecoverable data
+1. Thanks David.
Le mer. 13 juil. 2022 à 23:43, José Armando García Sancio
a écrit :
> +1. Thanks for volunteering David.
>
> --
> -José
>
API with Pattern, but instead we still use Pattern
> while just documenting that our subscription may be rejected by the server.
> Since the incompatible case is a very rare scenario I felt using an
> overloaded `String` based subscription may be more vulnerable to various
> invalid re
e metadata lookup on the server for both
paths but I do agree with your point. As a second though, using topic
ids may be better here for the delete and recreation case. Also, I
suppose that we may allow users to subscribe with topic ids in the
future because that is the only way to be really robu
SubscribedTopidIds instead of
> > SubscribedTopicNames in ConsumerGroupHeartbeatRequest? Is the idea that
> > since we have to resolve the regex on the server, we can do the same for
> > the topic name? The difference is that sending the regex is more efficient
> > wh
n, the KIP title
> > should also be updated.
> >
> > Luke
> >
> > On Fri, Jun 24, 2022 at 8:33 PM David Jacot
> > wrote:
> >
> > > Thanks for the KIP, Artem.
> > >
> > > I am +1 (binding).
> > >
> > > A smal
+1 (binding). Thanks for the KIP! It is a useful addition.
Best,
David
On Wed, Jul 6, 2022 at 9:10 PM Colin McCabe wrote:
>
> +1 (binding).
>
> thanks, Alexandre.
>
> On Mon, Jun 27, 2022, at 05:15, Alexandre Garnier wrote:
> > Hello!
> >
> > A little ping on this vote.
> >
> > Thanks.
> >
> > L
Thanks for the KIP, Omnia! +1 (binding)
On Wed, Jul 6, 2022 at 5:02 PM Omnia Ibrahim wrote:
>
> Hi,
> Can we have one last binding vote for this KIP, please?
>
> Omnia
>
> On Tue, Jun 28, 2022 at 3:36 PM Omnia Ibrahim
> wrote:
>
> > Thanks, Tom, I have updated the KIP to reflect these minor poin
Hi all,
I would like to start a discussion thread on KIP-848: The Next
Generation of the Consumer Rebalance Protocol. With this KIP, we aim
to make the rebalance protocol (for consumers) more reliable, more
scalable, easier to implement for clients, and easier to debug for
operators.
The KIP is h
David Jacot created KAFKA-14048:
---
Summary: The Next Generation of the Consumer Rebalance Protocol
Key: KAFKA-14048
URL: https://issues.apache.org/jira/browse/KAFKA-14048
Project: Kafka
Issue
Hi Guozhang,
Thanks for the KIP!
I agree with Luke. `requireStable` seems more consistent.
Regarding the kafka-consumer-group command line tool, I wonder if
there is real value in doing it. We don't necessarily have to add all
the options to it but we could if it is proven to be useful. Anyway,
Thanks for the KIP.
I read it and I am also worried by the complexity of the new
configurations. They are not easy to grasp. I need to digest it a bit more,
I think.
Best,
David
Le mer. 29 juin 2022 à 02:25, Matthias J. Sax a écrit :
> Thanks for the KIP.
>
> I don't think I fully digested the
Thanks for the KIP, Artem.
I am +1 (binding).
A small nit: ProducerIdCount should be used in the motivation.
Best,
David
On Thu, Jun 23, 2022 at 10:26 PM Artem Livshits
wrote:
>
> Hello,
>
> I'd like to start a vote on KIP-847
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-847%3A+Add+
Hi Artem,
The KIP LGTM.
Thanks,
David
On Tue, Jun 21, 2022 at 9:32 PM Artem Livshits
wrote:
>
> If there is no other feedback I'm going to start voting in a couple days.
>
> -Artem
>
> On Fri, Jun 17, 2022 at 3:50 PM Artem Livshits
> wrote:
>
> > Thank you for your feedback. Updated the KIP a
David Jacot created KAFKA-14013:
---
Summary: Limit the length of the `reason` field sent on the wire
Key: KAFKA-14013
URL: https://issues.apache.org/jira/browse/KAFKA-14013
Project: Kafka
Issue
[
https://issues.apache.org/jira/browse/KAFKA-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13998.
-
Resolution: Fixed
> JoinGroupRequestData 'reason' can
[
https://issues.apache.org/jira/browse/KAFKA-13916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13916.
-
Fix Version/s: 3.3.0
Resolution: Fixed
> Fenced replicas should not be allowed to j
tion%2Bin%2BDescribeQuorumResponse%2Babout%2BVoter%2BLag&source=gmail-imap&ust=165576000900&usg=AOvVaw3ZhA-Qvc0rZBYddc4u9667>
> >>
> >> Thanks
> >> - Niket
> >>
> >>
> >>> On May 24, 2022, at 2:30 PM, José Armando G
David Jacot created KAFKA-13975:
---
Summary: Mechanism to gate advertised APIs/versions based on
MetadataVersion
Key: KAFKA-13975
URL: https://issues.apache.org/jira/browse/KAFKA-13975
Project: Kafka
David Jacot created KAFKA-13974:
---
Summary: Rename `INVALID_UPDATE_VERSION` to
`INVALID_PARTITION_EPOCH`
Key: KAFKA-13974
URL: https://issues.apache.org/jira/browse/KAFKA-13974
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-13944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13944.
-
Fix Version/s: 3.3.0
Assignee: David Jacot (was: Jose Armando Garcia Sancio
David Jacot created KAFKA-13962:
---
Summary: KRaft StripedReplicaPlacer should handle replicas in
controlled shutdown
Key: KAFKA-13962
URL: https://issues.apache.org/jira/browse/KAFKA-13962
Project
Hi José,
KIP-841 has been accepted. Could we add it to the release plan?
Thanks,
David
On Wed, May 11, 2022 at 11:04 PM Chris Egerton wrote:
>
> Hi José,
>
> Could we add KIP-618 (
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-618%3A+Exactly-Once+Support+for+Source+Connectors)
> to th
Thanks all!
The vote passes with binding +1 votes from Colin, David, José and myself.
David
On Fri, Jun 3, 2022 at 2:14 AM José Armando García Sancio
wrote:
>
> Thanks for proposing this improvement David Jacot. I think it is going
> to make the graceful shutdown process much more
That's correct.
David
On Fri, Jun 3, 2022 at 2:11 AM José Armando García Sancio
wrote:
>
> David Jacot wrote:
> > At the moment, the KIP stipulates that the broker remains in
> > InControlledShutdown state until it is re-registered with a new
> > incarnation id. T
adataVersion since we are adding a new
> field to a metadata record. Otherwise we might have trouble downgrading the
> software if this field has been serialized.
>
> Cheers,
> David
>
> On Thu, Jun 2, 2022 at 11:04 AM David Jacot
> wrote:
>
> > Hi José,
> >
&g
Hi José,
At the moment, the KIP stipulates that the broker remains in
InControlledShutdown state until it is re-registered with a new
incarnation id. This implies that a broker can be both fenced and in
controlled shutdown state. We could make them mutually exclusive but I
think that there is valu
names?
>
> Ismael
>
> On Tue, May 31, 2022, 6:36 AM David Jacot
> wrote:
>
> > Hi all,
> >
> > Thanks for your feedback.
> >
> > I just updated the KIP as follows:
> > * I propose to add a `TopicId` field at the same time while we are
PLICA. This is very important for error codes so we
> > can track which ones are returned in which RPC version. I also wonder
>
> Here I'm referring to AlterPartitionResponse.json
>
> cheers,
> Colin
>
> >
> >
> > On Tue, May 31, 2022, at 08:36, David Jacot wrote:
> >> Hi folks,
> >>
> >> I'd like to start a vote for KIP-841:
> >> https://cwiki.apache.org/confluence/x/phmhD.
> >>
> >> Thanks,
> >> David
Hi folks,
I'd like to start a vote for KIP-841:
https://cwiki.apache.org/confluence/x/phmhD.
Thanks,
David
Hi all,
Thanks for your feedback.
I just updated the KIP as follows:
* I propose to add a `TopicId` field at the same time while we are bumping
the AlterPartition API version.
* I propose to add the `InShuttingDown` field to the registration records to
track if a broker is in controlled shutdown.
Hi all,
Looking at the current Metrics' API, we have `sensor` which gets or creates
a sensor. How about using `metric` to follow the same naming convention?
Best,
David
On Mon, May 30, 2022 at 9:18 AM Bruno Cadonna wrote:
>
> Hi Sagar,
> Hi Ismael,
>
> what about getOrCreateMetric()?
>
> Best,
+1. Thanks Colin!
On Tue, May 24, 2022 at 4:50 AM Luke Chen wrote:
>
> +1 from me.
> Kraft is coming!!!
>
> Luke
>
> On Tue, May 24, 2022 at 7:26 AM Israel Ekpo wrote:
>
> > +1 (non-binding) from me.
> >
> > I am very happy to finally see this.
> >
> > On Mon, May 23, 2022 at 6:08 PM Jason Gusta
+1 (binding)
Thanks for the KIP!
David
Le ven. 20 mai 2022 à 21:08, David Arthur a écrit :
> Hey Niket, +1 (binding) from me.
>
> -David
>
> On Thu, May 19, 2022 at 2:07 PM José Armando García Sancio
> wrote:
>
> > Hey Niket,
> >
> > I took a look at the latest KIP. It looks like QuorumInfo.R
This KIP is pretty straight forward. I will start a vote on Monday
if no one objects.
Best,
David
On Wed, May 18, 2022 at 5:55 PM David Jacot wrote:
>
> Hi,
>
> I created a small KIP to strengthen the AlterPartition API in KRaft mode:
> https://cwiki.apache.org/confluence/x/p
David Jacot created KAFKA-13916:
---
Summary: Fenced replicas should not be allowed to join the ISR in
KRaft (KIP-841)
Key: KAFKA-13916
URL: https://issues.apache.org/jira/browse/KAFKA-13916
Project
Hi Niket,
Thanks for the KIP. I have a few minor comments:
1. We should keep DescribeQuorumResult's constructor package-private
for now in my opinion. We have been debating about this in KIP-692 and
KIP-777 but as we haven't reached a consensus yet, we should be on the
conservative side here.
2.
Hi,
I created a small KIP to strengthen the AlterPartition API in KRaft mode:
https://cwiki.apache.org/confluence/x/phmhD
Let me know what you think.
Best,
David
eal-time streaming applications that transform or react
> to the streams of data.
>
>
> Apache Kafka is in use at large and small companies worldwide, including
> Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
> Target, The New York Times, Uber, Yelp, and
[
https://issues.apache.org/jira/browse/KAFKA-12703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-12703.
-
Fix Version/s: 3.3.0
Resolution: Fixed
> Allow unencrypted private keys when using
[
https://issues.apache.org/jira/browse/KAFKA-13790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13790.
-
Fix Version/s: 3.3.0
Reviewer: Jason Gustafson
Resolution: Fixed
Thanks for running the release, Bruno.
I performed the following validations:
* Verified all checksums and signatures.
* Built from source and ran unit tests.
* Ran the first quickstart steps for both ZK and KRaft.
* Spotchecked the doc and the Javadocs.
+1 (binding)
Best,
David
On Thu, May 5,
Thanks for running the release, Tom.
I performed the following validations:
* Verified all checksums and signatures.
* Built from source and ran unit tests.
* Ran the first quickstart steps for both ZK and KRaft.
* Spotchecked the Javadocs.
I noticed the same issues as others on the website. I ch
David Jacot created KAFKA-13844:
---
Summary: Pull Partition's volatile fields into a consolidate
`PartitionState`
Key: KAFKA-13844
URL: https://issues.apache.org/jira/browse/KAFKA-13844
Project:
[
https://issues.apache.org/jira/browse/KAFKA-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13542.
-
Fix Version/s: 3.2.0
(was: 3.3.0)
Resolution: Fixed
> Utilize
[
https://issues.apache.org/jira/browse/KAFKA-13828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13828.
-
Fix Version/s: 3.2.0
Resolution: Fixed
> Ensure reasons sent by the consumer are sm
David Jacot created KAFKA-13828:
---
Summary: Ensure reasons sent by the consumer are small
Key: KAFKA-13828
URL: https://issues.apache.org/jira/browse/KAFKA-13828
Project: Kafka
Issue Type: Bug
Hi Tom,
Thanks for running the release. I wonder if we should include:
https://github.com/apache/kafka/commit/134c432d6452de1bfb99d0f6b455a58c16bc626a.
This is a follow up of KAFKA-13794. What do you think?
Best,
David
On Fri, Apr 8, 2022 at 6:18 PM Tom Bentley wrote:
>
> Hello Kafka users, de
[
https://issues.apache.org/jira/browse/KAFKA-13801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13801.
-
Fix Version/s: 3.3.0
Reviewer: David Jacot
Assignee: Xavier Léauté
[
https://issues.apache.org/jira/browse/KAFKA-13778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13778.
-
Fix Version/s: 3.3.0
Reviewer: David Jacot
Resolution: Fixed
> Fetch f
have removed the prefixing. It does not bring much anyway as
we are still able to distinguish a custom reason from the default one.
[1] https://github.com/apache/kafka/pull/11873
Best,
David
On Wed, Dec 1, 2021 at 2:17 PM David Jacot wrote:
>
> Hi all,
>
> With 4 binding +1 votes (G
[
https://issues.apache.org/jira/browse/KAFKA-13783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13783.
-
Resolution: Fixed
> Remove reason prefixing in JoinGroupRequest and LeaveGroupRequ
David Jacot created KAFKA-13783:
---
Summary: Remove reason prefixing in JoinGroupRequest and
LeaveGroupRequest
Key: KAFKA-13783
URL: https://issues.apache.org/jira/browse/KAFKA-13783
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-13767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13767.
-
Reviewer: David Jacot
Resolution: Fixed
> Fetch from consumers should return immediat
+1 (binding). Thanks for the KIP.
Best,
David
Le ven. 25 mars 2022 à 07:11, Luke Chen a écrit :
> Hi Sergio,
>
> Thanks for the KIP!
> +1(binding) from me.
>
> Thank you.
> Luke
>
> On Fri, Mar 25, 2022 at 1:40 PM Sergio Daniel Troiano
> wrote:
>
> > Hi lads,
> >
> > I would like to start the
st regards
> Sergio Troiano
>
> On Fri, 25 Mar 2022 at 06:50, David Jacot wrote:
>
> > Hi Sergio,
> >
> > I made a suggestion a few weeks ago about the name about the parameter but
> > haven’t got a response for it. Did you consider it?
> >
>
Hi Sergio,
I made a suggestion a few weeks ago about the name about the parameter but
haven’t got a response for it. Did you consider it?
Do we need to update the rejected alternatives section to mention the
alternative options discussed in this thread?
Thanks,
David
Le ven. 25 mars 2022 à 03:4
Hi all,
Thanks Dejan for bringing this up. Relaxing this constraint seems
reasonable to me. I guess we would have to relax it for the keystores
at some point in the future as well (with Java 18).
Let's wait a few days to see what others think about this.
Best,
David
On Wed, Mar 23, 2022 at 8:46
Hi Artem,
Thanks for the KIP. This is a really nice improvement!
+1 (binding) from me.
David
On Tue, Mar 22, 2022 at 9:35 PM Jun Rao wrote:
>
> Hi, Artem,
>
> Thanks for the KIP. +1 from me.
>
> Jun
>
> On Mon, Mar 21, 2022 at 4:52 PM Artem Livshits
> wrote:
>
> > Hi all,
> >
> > I'd like to
[
https://issues.apache.org/jira/browse/KAFKA-13752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13752.
-
Fix Version/s: 3.2.0
3.1.1
3.3.0
Resolution: Fixed
[
https://issues.apache.org/jira/browse/KAFKA-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13497.
-
Fix Version/s: 3.2.0
Reviewer: David Jacot
Resolution: Fixed
> Debug
[
https://issues.apache.org/jira/browse/KAFKA-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13584.
-
Resolution: Fixed
Fixed by
https://github.com/apache/kafka/commit
[
https://issues.apache.org/jira/browse/KAFKA-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13750.
-
Fix Version/s: 3.2.0
3.1.1
3.0.2
Resolution: Fixed
[
https://issues.apache.org/jira/browse/KAFKA-13509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13509.
-
Reviewer: David Jacot
Resolution: Fixed
> Support max timestamp in GetOffsetSh
+1. Thanks Tom!
Le mer. 9 mars 2022 à 19:10, Bill Bejeck a écrit :
> Thanks Tom! It's a +1 for me.
>
> -Bill
>
> On Wed, Mar 9, 2022 at 12:00 PM Ismael Juma wrote:
>
> > Thanks Tom. +1
> >
> > Ismael
> >
> >
> > On Wed, Mar 9, 2022 at 8:10 AM Tom Bentley wrote:
> >
> > > Hi,
> > >
> > > I'd l
Thanks for running the release, Mickael.
I performed the following validations:
* Verified all checksums and signatures.
* Built from source and ran unit tests.
* Ran the first quickstart steps for both ZK and KRaft.
* Spotchecked the Javadocs.
However, the document still references 3.0.0 in all
Hi Sergio,
I wonder if « max-bytes » would be a better name than « max-batches-size ».
The intend is more explicit. What do you think?
Best,
David
Le sam. 5 mars 2022 à 10:36, Luke Chen a écrit :
> Hi Sergio,
>
> Thanks for the explanation! Very clear!
> I think we should put this example and
[
https://issues.apache.org/jira/browse/KAFKA-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13706.
-
Fix Version/s: 3.2.0
Reviewer: David Jacot
Assignee: Vincent Jiang
Hi Artem,
Thanks for the KIP! I have a few comments:
1. In the preamble of the proposed change section, there is still a
mention of the
-1 approach. My understanding is that we have moved away from it now.
2. I am a bit concerned by the trick suggested about the DefaultPartitioner and
the Unifor
+1 (binding). Thanks for the KIP!
On Fri, Jan 28, 2022 at 6:13 PM Tom Bentley wrote:
>
> Hi Luke,
>
> Thanks for the KIP, +1 (binding).
>
> Kind regards,
>
> Tom
>
> On Wed, 19 Jan 2022 at 13:16, Luke Chen wrote:
>
> > Hi all,
> >
> > Bump this thread to see if there are other comments to this K
> - 4 +1(binding) votes (Luke, David, Mickael and John)
>
> Thanks to all that participated in the discussion and voting,
>
> --
> Ziming Deng
>
>
> > On Feb 22, 2022, at 2:56 PM, David Jacot wrote:
> >
> > For reference, here is the KIP:
> > https://
) {
> return generationId;
> }
>
> Thank you.
> Luke
>
> On Mon, Feb 21, 2022 at 5:24 PM David Jacot
> wrote:
>
> > Hi Luke,
> >
> > I apologize for my late reply. I was out for a while.
> >
> > Coming back to my previous point, could you
For reference, here is the KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-815%3A++Support+max-timestamp+in+GetOffsetShell
Thanks for the KIP! +1 (binding)
Best,
David
Le mar. 22 févr. 2022 à 04:03, deng ziming a
écrit :
> Hey all, I'm starting the voting on KIP-815.
>
> This suppor
Hi Matthew,
Thanks for the KIP. I have a few minor comments:
1. In the public interface section, could we spell out
the configurations that we are changing with this
KIP? The name does not change but the semantic is
so it is good to be clear.
2. In the proposed changes section, I would rather
me
rations, the main difference
> are default.api.timeout.ms <http://default.api.timeout.ms/>, retries,
> request.timeout.ms <http://request.timeout.ms/>,metadata.max.age.ms
> <http://metadata.max.age.ms/>. Please take a look again when you are free.
>
> >
rev-owned partitions
> > > on the subscription protocol directly. So we can add the `StickyAssignor`
> > > in your paragraph talking about `CooperativeStickyAssignor` as well.
> > >
> > > * This sentence: "otherwise, we'll take the ownedPartitions as d
[
https://issues.apache.org/jira/browse/KAFKA-13435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13435.
-
Reviewer: Jason Gustafson
Resolution: Fixed
> Static membership protocol should let
[
https://issues.apache.org/jira/browse/KAFKA-13636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-13636.
-
Fix Version/s: 3.0.1
2.8.2
3.2.0
3.1.1
+1, thanks!
Le lun. 7 févr. 2022 à 17:41, José Armando García Sancio
a écrit :
> Thanks for the vote Jason.
>
> This is a friendly reminder to vote on this KIP.
>
> --
> -José
>
Hi team,
I find our ever growing back of PRs a little frustrating, don't
you? I just made a pass over all the list and a huge chunk
of the PRs are abandoned, outdated or irrelevant with the
current code base. For instance, we still have PRs opened
back in 2015.
There is not a Github Action [1] fo
Hi Dongjin,
Thanks for the KIP.
It is not so clear to me why we decided not to support OFF in the
first place. I understand that entirely disabling a logger is rare.
I find the KIP a bit week at the moment for two reasons:
1) The KIP says that the levels that we use are not fully
consistent wit
nGroupRequest` instead, and also add a field
> >> into `JoinGroupResponse` in `JoinGroupResponseMember` field. That way, the
> >> broker can identify the old member from `JoinGroupRequest`. And the
> >> assignor can also get the "generation" info via the `Subscription`
&g
+1. Thanks for volunteering, Bruno!
Le ven. 4 févr. 2022 à 16:03, Bruno Cadonna a écrit :
> Hi,
>
> I'd like to volunteer to be the release manager for our next
> feature release, 3.2.0. If there are no objections, I'll send
> out the release plan soon.
>
> Best,
> Bruno
>
Sancio
wrote:
>
> Thanks for the feedback David Jacot
>
> David Jacot wrote:
> > I have one question regarding how fetch from followers will
> > work when the leader is recovering. My understanding is that
> > the leader will reject any produce and fetch requests with a
&g
401 - 500 of 964 matches
Mail list logo
