[jira] [Resolved] (KAFKA-14279) Add 3.3.1 to broker/client and stream upgrade/compatibility tests

[Matthias J. Sax (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias J. Sax resolved KAFKA-14279.
-
Resolution: Fixed

> Add 3.3.1 to broker/client and stream upgrade/compatibility tests
> -
>
> Key: KAFKA-14279
> URL: https://issues.apache.org/jira/browse/KAFKA-14279
> Project: Kafka
>  Issue Type: Task
>  Components: clients, core, streams, system tests
>Reporter: José Armando García Sancio
>Assignee: José Armando García Sancio
>Priority: Blocker
> Fix For: 3.4.0
>
>
> Per the penultimate bullet on the [release 
> checklist|https://cwiki.apache.org/confluence/display/KAFKA/Release+Process#ReleaseProcess-Afterthevotepasses],
>  Kafka v3.3.0 is released. We should add this version to the system tests.
> Example PRs:
>  * Broker and clients: [https://github.com/apache/kafka/pull/6794]
>  * Streams: [https://github.com/apache/kafka/pull/6597/files]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #1498

[Apache Jenkins Server]

See 

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.4 #34

[Apache Jenkins Server]

See 

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #1497

[Apache Jenkins Server]

See 

Jenkins build is unstable: Kafka » Kafka Branch Builder » 3.4 #33

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-896: Remove old client protocol API versions in Kafka 4.0

[Jun Rao]

Hi, Ismael,

Thanks for the reply.

2. Yes, that makes sense.

Jun

On Mon, Jan 9, 2023 at 11:26 AM Ismael Juma  wrote:

> Hi Jun,
>
> Thanks for the feedback.
>
> 1. Good question. I was looking at the IBP issue as more of an inter broker
> protocol communication thing and hence I thought we'd cover that as part of
> the KIP that modernizes that aspect (yet to be written). I filed a JIRA
> recently that shares some of the thinking:
> https://issues.apache.org/jira/browse/KAFKA-14552. I was hoping we would
> tackle the details of that as part of the zk deprecation/removal. You're
> right though that we need to deprecate IBP before 2.1 as part of this KIP
> since we are removing some of the protocol API versions that would be
> required for that to work. I'll update the KIP to include this.
>
> 2. I believe they are all introduced after 2.1, yes. This is what I used as
> the source for 2.1:
>
> https://github.com/apache/kafka/blob/2.1/clients/src/main/java/org/apache/kafka/common/protocol/ApiKeys.java#L189
> .
> Note that I excluded inter broker protocol APIs like LeaderAndIsr,
> StopReplica and others for the reason I explained in `1`. Does that make
> sense?
>
> Ismael
>
> On Mon, Jan 9, 2023 at 11:01 AM Jun Rao  wrote:
>
> > Hi, Ismael,
> >
> > Thanks for the KIP. A couple of comments.
> >
> > 1. Should we deprecate IBPs before 2.1 too?
> >
> > 2. There seem to be more requests than those listed in the KIP. Are they
> > all introduced after 2.1?
> >
> > Thanks,
> >
> > Jun
> >
> >
> >
> > On Sat, Jan 7, 2023 at 5:13 PM Ismael Juma  wrote:
> >
> > > Hi all,
> > >
> > > I updated the KIP to make it explicit that the Java clients shipped
> with
> > > Apache Kafka 4.0 would only be guaranteed to work with brokers running
> > > Apache Kafka 2.1 or newer, since they too would no longer have access
> to
> > > the removed protocol APIs. Thanks to Jason for asking about this aspect
> > > offline.
> > >
> > > I will leave this KIP open for discussion for another couple or weeks
> or
> > > so. Please do share your thoughts given the high impact of the change.
> > >
> > > Ismael
> > >
> > > On Tue, Jan 3, 2023 at 8:17 AM Ismael Juma  wrote:
> > >
> > > > Hi all,
> > > >
> > > > I would like to start a discussion regarding the removal of very old
> > > > client protocol API versions in Apache Kafka 4.0 to improve
> > > maintainability
> > > > & supportability of Kafka. Please take a look at the proposal:
> > > >
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-896%3A+Remove+old+client+protocol+API+versions+in+Kafka+4.0
> > > >
> > > > Ismael
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-890 Server Side Defense

[Justine Olshan]

Hey all, I've updated the KIP to incorporate Jason's suggestions.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-890%3A+Transactions+Server-Side+Defense


1. Use AddPartitionsToTxn + verify flag to check on old clients
2. Updated AddPartitionsToTxn API to support transaction batching
3. Mention IBP bump
4. Mention auth change on new AddPartitionsToTxn version.

I'm planning on opening a vote soon.
Thanks,
Justine

On Fri, Jan 6, 2023 at 3:32 PM Justine Olshan  wrote:

> Thanks Jason. Those changes make sense to me. I will update the KIP.
>
>
>
> On Fri, Jan 6, 2023 at 3:31 PM Jason Gustafson 
> wrote:
>
>> Hey Justine,
>>
>> > I was wondering about compatibility here. When we send requests
>> between brokers, we want to ensure that the receiving broker understands
>> the request (specifically the new fields). Typically this is done via
>> IBP/metadata version.
>> I'm trying to think if there is a way around it but I'm not sure there is.
>>
>> Yes. I think we would gate usage of this behind an IBP bump. Does that
>> seem
>> reasonable?
>>
>> > As for the improvements -- can you clarify how the multiple
>> transactional
>> IDs would help here? Were you thinking of a case where we wait/batch
>> multiple produce requests together? My understanding for now was 1
>> transactional ID and one validation per 1 produce request.
>>
>> Each call to `AddPartitionsToTxn` is essentially a write to the
>> transaction
>> log and must block on replication. The more we can fit into a single
>> request, the more writes we can do in parallel. The alternative is to make
>> use of more connections, but usually we prefer batching since the network
>> stack is not really optimized for high connection/request loads.
>>
>> > Finally with respect to the authorizations, I think it makes sense to
>> skip
>> topic authorizations, but I'm a bit confused by the "leader ID" field.
>> Wouldn't we just want to flag the request as from a broker (does it matter
>> which one?).
>>
>> We could also make it version-based. For the next version, we could
>> require
>> CLUSTER auth. So clients would not be able to use the API anymore, which
>> is
>> probably what we want.
>>
>> -Jason
>>
>> On Fri, Jan 6, 2023 at 10:43 AM Justine Olshan
>> 
>> wrote:
>>
>> > As a follow up, I was just thinking about the batching a bit more.
>> > I suppose if we have one request in flight and we queue up the other
>> > produce requests in some sort of purgatory, we could send information
>> out
>> > for all of them rather than one by one. So that would be a benefit of
>> > batching partitions to add per transaction.
>> >
>> > I'll need to think a bit more on the design of this part of the KIP, and
>> > will update the KIP in the next few days.
>> >
>> > Thanks,
>> > Justine
>> >
>> > On Fri, Jan 6, 2023 at 10:22 AM Justine Olshan 
>> > wrote:
>> >
>> > > Hey Jason -- thanks for the input -- I was just digging a bit deeper
>> into
>> > > the design + implementation of the validation calls here and what you
>> say
>> > > makes sense.
>> > >
>> > > I was wondering about compatibility here. When we send requests
>> > > between brokers, we want to ensure that the receiving broker
>> understands
>> > > the request (specifically the new fields). Typically this is done via
>> > > IBP/metadata version.
>> > > I'm trying to think if there is a way around it but I'm not sure there
>> > is.
>> > >
>> > > As for the improvements -- can you clarify how the multiple
>> transactional
>> > > IDs would help here? Were you thinking of a case where we wait/batch
>> > > multiple produce requests together? My understanding for now was 1
>> > > transactional ID and one validation per 1 produce request.
>> > >
>> > > Finally with respect to the authorizations, I think it makes sense to
>> > skip
>> > > topic authorizations, but I'm a bit confused by the "leader ID" field.
>> > > Wouldn't we just want to flag the request as from a broker (does it
>> > matter
>> > > which one?).
>> > >
>> > > I think I want to adopt these suggestions, just had a few questions on
>> > the
>> > > details.
>> > >
>> > > Thanks,
>> > > Justine
>> > >
>> > > On Thu, Jan 5, 2023 at 5:05 PM Jason Gustafson
>> > 
>> > > wrote:
>> > >
>> > >> Hi Justine,
>> > >>
>> > >> Thanks for the proposal.
>> > >>
>> > >> I was thinking about the implementation a little bit. In the current
>> > >> proposal, the behavior depends on whether we have an old or new
>> client.
>> > >> For
>> > >> old clients, we send `DescribeTransactions` and verify the result and
>> > for
>> > >> new clients, we send `AddPartitionsToTxn`. We might be able to
>> simplify
>> > >> the
>> > >> implementation if we can use the same request type. For example,
>> what if
>> > >> we
>> > >> bump the protocol version for `AddPartitionsToTxn` and add a
>> > >> `validateOnly`
>> > >> flag? For older versions, we can set `validateOnly=true` so that the
>> > >> request only returns successfully if the partition had already been
>> > added.
>> > >> For new

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.4 #32

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 521713 lines...]
[2023-01-09T22:01:29.987Z] > Task 
:connect:api:publishMavenJavaPublicationToMavenLocal
[2023-01-09T22:01:29.987Z] > Task :connect:api:publishToMavenLocal
[2023-01-09T22:01:30.919Z] 
[2023-01-09T22:01:30.919Z] > Task :streams:javadoc
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:890:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:919:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:939:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:854:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:890:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:919:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:939:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/Produced.java:84:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/Produced.java:136:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/Produced.java:147:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/Repartitioned.java:101:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:30.919Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/kstream/Repartitioned.java:167:
 warning - Tag @link: reference not found: DefaultPartitioner
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/TopologyConfig.java:62:
 warning - Tag @link: missing '#': "org.apache.kafka.streams.StreamsBuilder()"
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/TopologyConfig.java:62:
 warning - Tag @link: can't find org.apache.kafka.streams.StreamsBuilder() in 
org.apache.kafka.streams.TopologyConfig
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/TopologyDescription.java:38:
 warning - Tag @link: reference not found: ProcessorContext#forward(Object, 
Object) forwards
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/query/Position.java:44:
 warning - Tag @link: can't find query(Query,
[2023-01-09T22:01:32.668Z]  PositionBound, boolean) in 
org.apache.kafka.streams.processor.StateStore
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:109:
 warning - Tag @link: reference not found: this#getResult()
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:116:
 warning - Tag @link: reference not found: this#getFailureReason()
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:116:
 warning - Tag @link: reference not found: this#getFailureMessage()
[2023-01-09T22:01:32.668Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.4/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:154:
 warning - Tag @link: reference not found: this#isSuccess()
[2023-01-09T22:01:32.668Z] 
/home/jen

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #1496

[Apache Jenkins Server]

See 

[GitHub] [kafka-site] edoardocomar merged pull request #475: add Edoardo to committer list

[GitBox]

edoardocomar merged PR #475:
URL: https://github.com/apache/kafka-site/pull/475


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] edoardocomar commented on pull request #475: add Edoardo to committer list

[GitBox]

edoardocomar commented on PR #475:
URL: https://github.com/apache/kafka-site/pull/475#issuecomment-1376356579

   > Approvals are not compulsory on kafka-site but typically it's still always 
best to get someone to take a look and approve. I've approved now, so feel free 
to merge.
   
   Thanks !


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mimaison commented on pull request #475: add Edoardo to committer list

[GitBox]

mimaison commented on PR #475:
URL: https://github.com/apache/kafka-site/pull/475#issuecomment-1376283918

   Approvals are not compulsory on kafka-site but typically it's still always 
best to get someone to take a look and approve. I've approved now, so feel free 
to merge.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [ANNOUNCE] New committer: Edoardo Comar

[Rajini Sivaram]

Congratulations, Edo!

Regards,

Rajini

On Mon, Jan 9, 2023 at 10:16 AM Tom Bentley  wrote:

> Congratulations!
>
> On Sun, 8 Jan 2023 at 01:14, Satish Duggana 
> wrote:
>
> > Congratulations, Edorado!
> >
> > On Sun, 8 Jan 2023 at 00:15, Viktor Somogyi-Vass
> >  wrote:
> > >
> > > Congrats Edoardo!
> > >
> > > On Sat, Jan 7, 2023, 18:15 Bill Bejeck  wrote:
> > >
> > > > Congratulations, Edoardo!
> > > >
> > > > -Bill
> > > >
> > > > On Sat, Jan 7, 2023 at 12:11 PM John Roesler 
> > wrote:
> > > >
> > > > > Congrats, Edoardo!
> > > > > -John
> > > > >
> > > > > On Fri, Jan 6, 2023, at 20:47, Matthias J. Sax wrote:
> > > > > > Congrats!
> > > > > >
> > > > > > On 1/6/23 5:15 PM, Luke Chen wrote:
> > > > > >> Congratulations, Edoardo!
> > > > > >>
> > > > > >> Luke
> > > > > >>
> > > > > >> On Sat, Jan 7, 2023 at 7:58 AM Mickael Maison <
> > > > mickael.mai...@gmail.com
> > > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Congratulations Edo!
> > > > > >>>
> > > > > >>>
> > > > > >>> On Sat, Jan 7, 2023 at 12:05 AM Jun Rao
>  > >
> > > > > wrote:
> > > > > 
> > > > >  Hi, Everyone,
> > > > > 
> > > > >  The PMC of Apache Kafka is pleased to announce a new Kafka
> > committer
> > > > > >>> Edoardo
> > > > >  Comar.
> > > > > 
> > > > >  Edoardo has been a long time Kafka contributor since 2016. His
> > major
> > > > >  contributions are the following.
> > > > > 
> > > > >  KIP-302: Enable Kafka clients to use all DNS resolved IP
> > addresses
> > > > >  KIP-277: Fine Grained ACL for CreateTopics API
> > > > >  KIP-136: Add Listener name to SelectorMetrics tags
> > > > > 
> > > > >  Congratulations, Edoardo!
> > > > > 
> > > > >  Thanks,
> > > > > 
> > > > >  Jun (on behalf of the Apache Kafka PMC)
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> >
> >
>

Re: [DISCUSS] KIP-896: Remove old client protocol API versions in Kafka 4.0

[Ismael Juma]

Hi Jun,

Thanks for the feedback.

1. Good question. I was looking at the IBP issue as more of an inter broker
protocol communication thing and hence I thought we'd cover that as part of
the KIP that modernizes that aspect (yet to be written). I filed a JIRA
recently that shares some of the thinking:
https://issues.apache.org/jira/browse/KAFKA-14552. I was hoping we would
tackle the details of that as part of the zk deprecation/removal. You're
right though that we need to deprecate IBP before 2.1 as part of this KIP
since we are removing some of the protocol API versions that would be
required for that to work. I'll update the KIP to include this.

2. I believe they are all introduced after 2.1, yes. This is what I used as
the source for 2.1:
https://github.com/apache/kafka/blob/2.1/clients/src/main/java/org/apache/kafka/common/protocol/ApiKeys.java#L189.
Note that I excluded inter broker protocol APIs like LeaderAndIsr,
StopReplica and others for the reason I explained in `1`. Does that make
sense?

Ismael

On Mon, Jan 9, 2023 at 11:01 AM Jun Rao  wrote:

> Hi, Ismael,
>
> Thanks for the KIP. A couple of comments.
>
> 1. Should we deprecate IBPs before 2.1 too?
>
> 2. There seem to be more requests than those listed in the KIP. Are they
> all introduced after 2.1?
>
> Thanks,
>
> Jun
>
>
>
> On Sat, Jan 7, 2023 at 5:13 PM Ismael Juma  wrote:
>
> > Hi all,
> >
> > I updated the KIP to make it explicit that the Java clients shipped with
> > Apache Kafka 4.0 would only be guaranteed to work with brokers running
> > Apache Kafka 2.1 or newer, since they too would no longer have access to
> > the removed protocol APIs. Thanks to Jason for asking about this aspect
> > offline.
> >
> > I will leave this KIP open for discussion for another couple or weeks or
> > so. Please do share your thoughts given the high impact of the change.
> >
> > Ismael
> >
> > On Tue, Jan 3, 2023 at 8:17 AM Ismael Juma  wrote:
> >
> > > Hi all,
> > >
> > > I would like to start a discussion regarding the removal of very old
> > > client protocol API versions in Apache Kafka 4.0 to improve
> > maintainability
> > > & supportability of Kafka. Please take a look at the proposal:
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-896%3A+Remove+old+client+protocol+API+versions+in+Kafka+4.0
> > >
> > > Ismael
> > >
> >
>

[GitHub] [kafka-site] edoardocomar commented on pull request #475: add Edoardo to committer list

[GitBox]

edoardocomar commented on PR #475:
URL: https://github.com/apache/kafka-site/pull/475#issuecomment-1376140418

   @mimaison @rajinisivaram 
   I do not understand if I should squash and merge myself or ask for approval 
... 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] KIP-896: Remove old client protocol API versions in Kafka 4.0

[Jun Rao]

Hi, Ismael,

Thanks for the KIP. A couple of comments.

1. Should we deprecate IBPs before 2.1 too?

2. There seem to be more requests than those listed in the KIP. Are they
all introduced after 2.1?

Thanks,

Jun



On Sat, Jan 7, 2023 at 5:13 PM Ismael Juma  wrote:

> Hi all,
>
> I updated the KIP to make it explicit that the Java clients shipped with
> Apache Kafka 4.0 would only be guaranteed to work with brokers running
> Apache Kafka 2.1 or newer, since they too would no longer have access to
> the removed protocol APIs. Thanks to Jason for asking about this aspect
> offline.
>
> I will leave this KIP open for discussion for another couple or weeks or
> so. Please do share your thoughts given the high impact of the change.
>
> Ismael
>
> On Tue, Jan 3, 2023 at 8:17 AM Ismael Juma  wrote:
>
> > Hi all,
> >
> > I would like to start a discussion regarding the removal of very old
> > client protocol API versions in Apache Kafka 4.0 to improve
> maintainability
> > & supportability of Kafka. Please take a look at the proposal:
> >
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-896%3A+Remove+old+client+protocol+API+versions+in+Kafka+4.0
> >
> > Ismael
> >
>

Re: [VOTE] 3.3.2 RC1

[José Armando García Sancio]

Hey Chris,

I started a run for the system tests. The commit is b66af662e6. I'll
message you again with a link to the results when it is done. Probably
at the end of the day today or tomorrow morning.

Thanks,
-- 
-José

Re: [VOTE] 3.3.2 RC1

[Tom Bentley]

+1 binding.

I have checked signatures, given the javadocs a quick look, followed the
quickstart for KRaft and run the tests.

Thanks Chris for running the release.

Tom



On Mon, 9 Jan 2023 at 15:29, Chris Egerton  wrote:

> Hi all,
>
> Thanks to everyone who has tested and voted for the release so far! Since
> we only have two binding votes so far, I'll be keeping the vote thread open
> until we either discover a blocker that requires a new release candidate to
> be generated, or get a third binding vote.
>
> For anyone following along, it may appear that there have already been
> three binding votes, but Satish's vote is actually non-binding since he is
> a committer, but not on the PMC (see the "Product Release" action in the
> project bylaws [1]). We've already clarified this offline and I'm only
> reiterating here to help prevent any confusion over the number of binding
> votes that have been cast. And either way--thank you for testing out the
> release, Satish!
>
> Cheers,
>
> Chris
>
> [1] -
> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Actions
>
> On Thu, Jan 5, 2023 at 9:45 AM Mickael Maison 
> wrote:
>
> > +1 binding
> >
> > - Checked signatures
> > - Ran quickstart with Scala 2.13 binaries
> > - Ran unit and integration tests
> >
> > Thanks Chris for running this release
> >
> >
> > On Wed, Jan 4, 2023 at 11:37 AM Satish Duggana  >
> > wrote:
> > >
> > > Hi Chris,
> > > Thanks for running the release.
> > >
> > > +1 (binding)
> > >
> > > - Verified signatures and artifacts
> > > - Ran testAll/releaseTarGzAll successfully with no failures.
> > > - Ran through quickstart of core/streams on builds generated from the
> > tag.
> > > - Ran a few internal apps targeting to topics on 3 node cluster.
> > >
> > > On Wed, 4 Jan 2023 at 00:49, Manikumar 
> > wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > +1 (binding)
> > > >
> > > > - verified the signatures, artifacts
> > > > - ran the tests on the source archive
> > > > - verified the quickstarts
> > > >
> > > > Thanks for running the release!
> > > >
> > > > Thanks,
> > > > Manikumar
> > > >
> > > >
> > > > On Fri, Dec 23, 2022 at 4:44 PM Federico Valeri <
> fedeval...@gmail.com>
> > wrote:
> > > > >
> > > > > Hi, I did the following to validate the release:
> > > > >
> > > > > - Checksums and signatures ok
> > > > > - Build from source using Java 17 and Scala 2.13 ok
> > > > > - Unit and integration tests ok
> > > > > - Quickstart in both ZK and KRaft modes ok
> > > > > - Test app with staging Maven artifacts ok
> > > > >
> > > > > +1 (non binding)
> > > > >
> > > > > Thanks
> > > > > Fede
> > > > >
> > > > > On Wed, Dec 21, 2022 at 11:21 PM Chris Egerton
> >  wrote:
> > > > > >
> > > > > > Hello Kafka users, developers and client-developers,
> > > > > >
> > > > > > This is the second candidate for release of Apache Kafka 3.3.2.
> > > > > >
> > > > > > This is a bugfix release with several fixes since the release of
> > 3.3.1. A
> > > > > > few of the major issues include:
> > > > > >
> > > > > > * KAFKA-14358 Users should not be able to create a regular topic
> > name
> > > > > > __cluster_metadata
> > > > > > KAFKA-14379 Consumer should refresh preferred read replica on
> > update
> > > > > > metadata
> > > > > > * KAFKA-13586 Prevent exception thrown during connector update
> from
> > > > > > crashing distributed herder
> > > > > >
> > > > > >
> > > > > > Release notes for the 3.3.2 release:
> > > > > >
> > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/RELEASE_NOTES.html
> > > > > >
> > > > > > *** Please download, test and vote by Friday, January 6, 2023,
> > 10pm UTC
> > > > > > (this date is chosen to accommodate the various upcoming holidays
> > that
> > > > > > members of the community will be taking and give everyone enough
> > time to
> > > > > > test out the release candidate, without unduly delaying the
> > release)
> > > > > >
> > > > > > Kafka's KEYS file containing PGP keys we use to sign the release:
> > > > > > https://kafka.apache.org/KEYS
> > > > > >
> > > > > > * Release artifacts to be voted upon (source and binary):
> > > > > > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/
> > > > > >
> > > > > > * Maven artifacts to be voted upon:
> > > > > >
> > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> > > > > >
> > > > > > * Javadoc:
> > > > > > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/javadoc/
> > > > > >
> > > > > > * Tag to be voted upon (off 3.3 branch) is the 3.3.2 tag:
> > > > > > https://github.com/apache/kafka/releases/tag/3.3.2-rc1
> > > > > >
> > > > > > * Documentation:
> > > > > > https://kafka.apache.org/33/documentation.html
> > > > > >
> > > > > > * Protocol:
> > > > > > https://kafka.apache.org/33/protocol.html
> > > > > >
> > > > > > The most recent build has had test failures. These all appear to
> > be due to
> > > > > > flakiness, but it would be nice if someone more familiar with the
> > failed
> > > > > > tests could confirm this. I may update this th

[jira] [Created] (KAFKA-14610) Publish Mirror Maker 2 offset syncs in task commit method

[Chris Egerton (Jira)]

Chris Egerton created KAFKA-14610:
-

 Summary: Publish Mirror Maker 2 offset syncs in task commit method
 Key: KAFKA-14610
 URL: https://issues.apache.org/jira/browse/KAFKA-14610
 Project: Kafka
  Issue Type: Improvement
  Components: mirrormaker
Reporter: Chris Egerton


Mirror Maker 2 periodically publishes offset sync messages to a Kafka topic 
that contains the corresponding upstream and downstream offsets for a 
replicated topic partition.

 

Currently, this publishing takes place inside the [commitRecord 
method|https://github.com/apache/kafka/blob/e38526e375389868664c8977c7a2125e5da2388c/connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorSourceTask.java#L192],
 which is invoked by the Kafka Connect framework after a source record has been 
successfully sent by its producer (i.e., ack'd by the requested number of 
brokers).

 

Mirror Maker 2 also has logic to limit the number of in-flight offset sync 
messages. Once ten messages have been dispatched to the producer used for 
offset syncs (which is a separate producer from the one that the Kafka Connect 
framework uses for sending records received from the [poll 
method|https://github.com/apache/kafka/blob/e38526e375389868664c8977c7a2125e5da2388c/connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorSourceTask.java#L134])
 that have not yet been ack'd by the requested number of brokers, Mirror Maker 
2 begins to skip sending offset sync messages, and will only resume sending 
messages once the number of in-flight offset syncs goes below 10, and new calls 
to the {{commitRecord}} method take place.

 

When bursts of throughput occur in replicated topic partitions, this can cause 
offset syncs to be dropped for long periods of time if an offset sync is 
skipped for some topic partition due to a high number of in-flight messages and 
then no further messages are read from that same topic partition for a while.

 

Instead, the task should cache offset syncs in its {{{}commitRecord method{}}}, 
and only actually send offset sync messages in its [commit 
method|https://github.com/apache/kafka/blob/e38526e375389868664c8977c7a2125e5da2388c/connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorSourceTask.java#L108],
 which is invoked periodically by the Kafka Connect framework. Any offset syncs 
that are skipped due to too many in-flight messages will then be automatically 
retried later when {{commit}} is re-invoked, regardless of whether any more 
records are read from the corresponding topic partition.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-14609) Kafka Streams Processor API cannot use state stores

[Bill Bejeck (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Bejeck resolved KAFKA-14609.
-
Resolution: Fixed

Fixed by https://issues.apache.org/jira/browse/KAFKA-14388

> Kafka Streams Processor API cannot use state stores
> ---
>
> Key: KAFKA-14609
> URL: https://issues.apache.org/jira/browse/KAFKA-14609
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 3.3.0
>Reporter: Philipp Schirmer
>Priority: Major
>
> The recently introduced Kafka Streams Processor API (since 3.3, 
> https://issues.apache.org/jira/browse/KAFKA-13654) likely has a bug with 
> regards to using state stores. The 
> [getStateStore|https://javadoc.io/static/org.apache.kafka/kafka-streams/3.3.1/org/apache/kafka/streams/processor/api/ProcessingContext.html#getStateStore-java.lang.String-]
>  method returns null, even though the store has been registered according to 
> the docs. The old transformer API still works. I created a small project that 
> demonstrates the behavior. It uses both methods to register a store for the 
> transformer, as well as the processor API: 
> https://github.com/bakdata/kafka-streams-state-store-demo/blob/main/src/test/java/com/bakdata/kafka/StreamsStateStoreTest.java



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] 3.3.2 RC1

[Chris Egerton]

Hi all,

Thanks to everyone who has tested and voted for the release so far! Since
we only have two binding votes so far, I'll be keeping the vote thread open
until we either discover a blocker that requires a new release candidate to
be generated, or get a third binding vote.

For anyone following along, it may appear that there have already been
three binding votes, but Satish's vote is actually non-binding since he is
a committer, but not on the PMC (see the "Product Release" action in the
project bylaws [1]). We've already clarified this offline and I'm only
reiterating here to help prevent any confusion over the number of binding
votes that have been cast. And either way--thank you for testing out the
release, Satish!

Cheers,

Chris

[1] -
https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Actions

On Thu, Jan 5, 2023 at 9:45 AM Mickael Maison 
wrote:

> +1 binding
>
> - Checked signatures
> - Ran quickstart with Scala 2.13 binaries
> - Ran unit and integration tests
>
> Thanks Chris for running this release
>
>
> On Wed, Jan 4, 2023 at 11:37 AM Satish Duggana 
> wrote:
> >
> > Hi Chris,
> > Thanks for running the release.
> >
> > +1 (binding)
> >
> > - Verified signatures and artifacts
> > - Ran testAll/releaseTarGzAll successfully with no failures.
> > - Ran through quickstart of core/streams on builds generated from the
> tag.
> > - Ran a few internal apps targeting to topics on 3 node cluster.
> >
> > On Wed, 4 Jan 2023 at 00:49, Manikumar 
> wrote:
> > >
> > > Hi Chris,
> > >
> > > +1 (binding)
> > >
> > > - verified the signatures, artifacts
> > > - ran the tests on the source archive
> > > - verified the quickstarts
> > >
> > > Thanks for running the release!
> > >
> > > Thanks,
> > > Manikumar
> > >
> > >
> > > On Fri, Dec 23, 2022 at 4:44 PM Federico Valeri 
> wrote:
> > > >
> > > > Hi, I did the following to validate the release:
> > > >
> > > > - Checksums and signatures ok
> > > > - Build from source using Java 17 and Scala 2.13 ok
> > > > - Unit and integration tests ok
> > > > - Quickstart in both ZK and KRaft modes ok
> > > > - Test app with staging Maven artifacts ok
> > > >
> > > > +1 (non binding)
> > > >
> > > > Thanks
> > > > Fede
> > > >
> > > > On Wed, Dec 21, 2022 at 11:21 PM Chris Egerton
>  wrote:
> > > > >
> > > > > Hello Kafka users, developers and client-developers,
> > > > >
> > > > > This is the second candidate for release of Apache Kafka 3.3.2.
> > > > >
> > > > > This is a bugfix release with several fixes since the release of
> 3.3.1. A
> > > > > few of the major issues include:
> > > > >
> > > > > * KAFKA-14358 Users should not be able to create a regular topic
> name
> > > > > __cluster_metadata
> > > > > KAFKA-14379 Consumer should refresh preferred read replica on
> update
> > > > > metadata
> > > > > * KAFKA-13586 Prevent exception thrown during connector update from
> > > > > crashing distributed herder
> > > > >
> > > > >
> > > > > Release notes for the 3.3.2 release:
> > > > >
> https://home.apache.org/~cegerton/kafka-3.3.2-rc1/RELEASE_NOTES.html
> > > > >
> > > > > *** Please download, test and vote by Friday, January 6, 2023,
> 10pm UTC
> > > > > (this date is chosen to accommodate the various upcoming holidays
> that
> > > > > members of the community will be taking and give everyone enough
> time to
> > > > > test out the release candidate, without unduly delaying the
> release)
> > > > >
> > > > > Kafka's KEYS file containing PGP keys we use to sign the release:
> > > > > https://kafka.apache.org/KEYS
> > > > >
> > > > > * Release artifacts to be voted upon (source and binary):
> > > > > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/
> > > > >
> > > > > * Maven artifacts to be voted upon:
> > > > >
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
> > > > >
> > > > > * Javadoc:
> > > > > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/javadoc/
> > > > >
> > > > > * Tag to be voted upon (off 3.3 branch) is the 3.3.2 tag:
> > > > > https://github.com/apache/kafka/releases/tag/3.3.2-rc1
> > > > >
> > > > > * Documentation:
> > > > > https://kafka.apache.org/33/documentation.html
> > > > >
> > > > > * Protocol:
> > > > > https://kafka.apache.org/33/protocol.html
> > > > >
> > > > > The most recent build has had test failures. These all appear to
> be due to
> > > > > flakiness, but it would be nice if someone more familiar with the
> failed
> > > > > tests could confirm this. I may update this thread with passing
> build links
> > > > > if I can get one, or start a new release vote thread if test
> failures must
> > > > > be addressed beyond re-running builds until they pass.
> > > > >
> > > > > Unit/integration tests:
> > > > >
> https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.3/142/testReport/
> > > > >
> > > > > José, would it be possible to re-run the system tests for 3.3 on
> the latest
> > > > > commit for 3.3 (e3212f2), and share the results on this thread?
> > > > >
> > > > > Cheers,
> > > > >
> > > > 

Re: [VOTE] KIP-710: Full support for distributed mode in dedicated MirrorMaker 2.0 clusters

[John Roesler]

Yes, you are!

Congrats again :)
-John

On Mon, Jan 9, 2023, at 08:25, Viktor Somogyi-Vass wrote:
> Hey all,
>
> Now that I'm a committer am I allowed to change my non-binding vote to
> binding to pass the KIP? :)
>
> On Thu, Nov 10, 2022 at 6:13 PM Greg Harris 
> wrote:
>
>> +1 (non-binding)
>>
>> Thanks for the KIP, this is an important improvement.
>>
>> Greg
>>
>> On Thu, Nov 10, 2022 at 7:21 AM John Roesler  wrote:
>>
>> > Thanks for the KIP, Daniel!
>> >
>> > I'm no MM expert, but I've read over the KIP and discussion, and it seems
>> > reasonable to me.
>> >
>> > I'm +1 (binding).
>> >
>> > Thanks,
>> > -John
>> >
>> > On 2022/10/22 07:38:38 Urbán Dániel wrote:
>> > > Hi everyone,
>> > >
>> > > I would like to start a vote on KIP-710 which aims to support running a
>> > > dedicated MM2 cluster in distributed mode:
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-710%3A+Full+support+for+distributed+mode+in+dedicated+MirrorMaker+2.0+clusters
>> > >
>> > > Regards,
>> > > Daniel
>> > >
>> > >
>> > > --
>> > > Ezt az e-mailt átvizsgálta az Avast AntiVirus szoftver.
>> > > www.avast.com
>> > >
>> >
>>

Re: [DISCUSS] KIP-709: Extend OffsetFetch requests to accept multiple group ids

[David Jacot]

Hi all,

I was looking at the OffsetFetchRequest in the context of KIP-848 and
I noticed something that I would like to discuss.

In the current implementation, when a group is specified multiple
times in the request, we ignore all occurrences but the last one. That
is because all groups are put in a Map so the last one wins. I find
this a bit strange because one case specifies multiple times the same
group but with different topics/partitions and he would get only a
response for the last one. This does not seem right to me. We could
return a response for each provided group (in the same order as in the
request). In practice, I suppose that no one uses the API this way and
note that it is not possible to do this with the admin client. What do
you think? Personally, I would consider this as a bug in the
implementation.

Best,
David

On Tue, Jul 12, 2022 at 7:43 PM Rajini Sivaram  wrote:
>
> Hi all,
>
> Following the PR discussion on this KIP's Admin API PR (
> https://github.com/apache/kafka/pull/10964), we have changed the Admin API
> proposed in this KIP to use a separate ListConsumerGroupOffsetsSpec class
> to specify per-group spec including partitions for which offsets are
> fetched.
>
> The new APIs are:
>
>
>- ListConsumerGroupOffsetsResult listConsumerGroupOffsets(MapListConsumerGroupOffsetsSpec> groupSpecs, ListConsumerGroupOffsetsOptions
>options);
>- ListConsumerGroupOffsetsResult listConsumerGroupOffsets(MapListConsumerGroupOffsetsSpec> groupSpecs);
>
>
> Using a spec class rather than directly setting partitions in the map
> allows us to evolve the group spec more easily in future. It also avoids a
> Map with null values for the case where all partitions of the groups are
> being fetched.
>
> We have also replaced the proposed method that returns Map KafkaFuture>>  in
> ListConsumerGroupOffsetsResult with a method that takes the groupId as
> argument to simplify the API. The new API is:
>
>- public KafkaFuture>
>partitionsToOffsetAndMetadata(String groupId);
>
>
> Please let me know if there are any concerns with these changes.
>
>
> Thank you,
>
> Rajini
>
>
> On Sat, Jul 3, 2021 at 12:18 AM Sanjana Kaundinya 
> wrote:
>
> > Hello Everyone,
> >
> > I recently opened a PR for KIP-709 and it was pointed out that we still
> > need to come to a consensus on the Admin APIs. Specifically the concern was
> > around the `ListConsumerGroupOffsetsOptions` class. Currently that class
> > contains a List that acts as a filter for the specific
> > topic partitions the client wants to fetch offsets for a specific group.
> > Originally I had planned to extend this by adding a map of type Map > List> so when specifying topic partitions, the called could
> > specify it on a per group basis with the `ListConsumerGroupOffsetsOptions`
> > class. However it was noted that this is not the typical way that the
> > “Options” class is used for the requests. Instead they’re normally used as
> > additional options for the request, and generally the data for the request
> > is passed in as a constructor. Since we are taking the time to change this
> > API, might as well try to use some best practices and change how we use the
> > `ListConsumerGroupOffsetsOptions` class. I propose we change the
> > `listConsumerGroupOffsets` API as follows:
> >
> > Earlier it was proposed that the following will be the method signatures
> > we would add to Admin.java:
> >
> > default ListConsumerGroupOffsetsResult
> > listConsumerGroupOffsets(List groupIds) {
> >return listConsumerGroupOffsets(groupIds, new
> > ListConsumerGroupOffsetsOptions(groupIds));
> > }
> > ListConsumerGroupOffsetsResult listConsumerGroupOffsets(List
> > groupIds, ListConsumerGroupOffsetsOptions options);
> >
> > I propose we change the signatures to the following instead:
> >
> > default ListConsumerGroupOffsetsResult
> > listConsumerGroupOffsets(Map>
> > groupToTopicPartitions) {
> > return listConsumerGroupOffsets(groupToTopicPartitions, new
> > ListConsumerGroupOffsetOptions());
> > }
> > ListConsumerGroupOffsetsResult list listConsumerGroupOffsets(Map > List> groupToTopicPartitions,
> > ListConsumerGroupOffsetOptions options);
> >
> > This way we are transferring the data for the requests passed in as
> > parameters and this frees up the ListConsumerGroupOffsetOptions class to be
> > used in the future to apply different options to the request. Eventually we
> > will deprecate the single group listConsumerGroupOffsets method, and with
> > that the ListConsumerGroupOffsetsOptions method signature will also be
> > different, no longer storing the data for the topic partitions that we want
> > to retrieve offsets for. In essence, as part of this change, we will leave
> > the ListConsumerGroupOffsetsOptions unchanged, and eventually remove the
> > List we store there when we remove the deprecated single
> > listConsumerGroupOffsets method.
> >
> > Appreciate any feedback/discussion on this - thank you!
> >
> > Cheers,
> > Sa

[jira] [Created] (KAFKA-14609) Kafka Streams Processor API cannot use state stores

[Philipp Schirmer (Jira)]

Philipp Schirmer created KAFKA-14609:


 Summary: Kafka Streams Processor API cannot use state stores
 Key: KAFKA-14609
 URL: https://issues.apache.org/jira/browse/KAFKA-14609
 Project: Kafka
  Issue Type: Bug
  Components: streams
Affects Versions: 3.3.0
Reporter: Philipp Schirmer


The recently introduced Kafka Streams Processor API (since 3.3, 
https://issues.apache.org/jira/browse/KAFKA-13654) likely has a bug with 
regards to using state stores. The 
[getStateStore|https://javadoc.io/static/org.apache.kafka/kafka-streams/3.3.1/org/apache/kafka/streams/processor/api/ProcessingContext.html#getStateStore-java.lang.String-]
 method returns null, even though the store has been registered according to 
the docs. The old transformer API still works. I created a small project that 
demonstrates the behavior. It uses both methods to register a store for the 
transformer, as well as the processor API: 
https://github.com/bakdata/kafka-streams-state-store-demo/blob/main/src/test/java/com/bakdata/kafka/StreamsStateStoreTest.java



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] KIP-710: Full support for distributed mode in dedicated MirrorMaker 2.0 clusters

[Viktor Somogyi-Vass]

Hey all,

Now that I'm a committer am I allowed to change my non-binding vote to
binding to pass the KIP? :)

On Thu, Nov 10, 2022 at 6:13 PM Greg Harris 
wrote:

> +1 (non-binding)
>
> Thanks for the KIP, this is an important improvement.
>
> Greg
>
> On Thu, Nov 10, 2022 at 7:21 AM John Roesler  wrote:
>
> > Thanks for the KIP, Daniel!
> >
> > I'm no MM expert, but I've read over the KIP and discussion, and it seems
> > reasonable to me.
> >
> > I'm +1 (binding).
> >
> > Thanks,
> > -John
> >
> > On 2022/10/22 07:38:38 Urbán Dániel wrote:
> > > Hi everyone,
> > >
> > > I would like to start a vote on KIP-710 which aims to support running a
> > > dedicated MM2 cluster in distributed mode:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-710%3A+Full+support+for+distributed+mode+in+dedicated+MirrorMaker+2.0+clusters
> > >
> > > Regards,
> > > Daniel
> > >
> > >
> > > --
> > > Ezt az e-mailt átvizsgálta az Avast AntiVirus szoftver.
> > > www.avast.com
> > >
> >
>

[jira] [Resolved] (KAFKA-14570) Problem description missing closing parenthesis symbol

[Mickael Maison (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mickael Maison resolved KAFKA-14570.

Fix Version/s: 3.5.0
   Resolution: Fixed

> Problem description missing closing parenthesis symbol
> --
>
> Key: KAFKA-14570
> URL: https://issues.apache.org/jira/browse/KAFKA-14570
> Project: Kafka
>  Issue Type: Improvement
>  Components: clients
>Reporter: iamazy
>Priority: Trivial
> Fix For: 3.5.0
>
>
> In 
> [verifyFullFetchResponsePartitions|https://github.com/apache/kafka/blob/ad94dc2134474c9d790fe0bb79c0d390c562846a/clients/src/main/java/org/apache/kafka/clients/FetchSessionHandler.java#L425-L449],
>  the problem description missing closing parenthesis symbol.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [ANNOUNCE] New committer: Edoardo Comar

[Tom Bentley]

Congratulations!

On Sun, 8 Jan 2023 at 01:14, Satish Duggana 
wrote:

> Congratulations, Edorado!
>
> On Sun, 8 Jan 2023 at 00:15, Viktor Somogyi-Vass
>  wrote:
> >
> > Congrats Edoardo!
> >
> > On Sat, Jan 7, 2023, 18:15 Bill Bejeck  wrote:
> >
> > > Congratulations, Edoardo!
> > >
> > > -Bill
> > >
> > > On Sat, Jan 7, 2023 at 12:11 PM John Roesler 
> wrote:
> > >
> > > > Congrats, Edoardo!
> > > > -John
> > > >
> > > > On Fri, Jan 6, 2023, at 20:47, Matthias J. Sax wrote:
> > > > > Congrats!
> > > > >
> > > > > On 1/6/23 5:15 PM, Luke Chen wrote:
> > > > >> Congratulations, Edoardo!
> > > > >>
> > > > >> Luke
> > > > >>
> > > > >> On Sat, Jan 7, 2023 at 7:58 AM Mickael Maison <
> > > mickael.mai...@gmail.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Congratulations Edo!
> > > > >>>
> > > > >>>
> > > > >>> On Sat, Jan 7, 2023 at 12:05 AM Jun Rao  >
> > > > wrote:
> > > > 
> > > >  Hi, Everyone,
> > > > 
> > > >  The PMC of Apache Kafka is pleased to announce a new Kafka
> committer
> > > > >>> Edoardo
> > > >  Comar.
> > > > 
> > > >  Edoardo has been a long time Kafka contributor since 2016. His
> major
> > > >  contributions are the following.
> > > > 
> > > >  KIP-302: Enable Kafka clients to use all DNS resolved IP
> addresses
> > > >  KIP-277: Fine Grained ACL for CreateTopics API
> > > >  KIP-136: Add Listener name to SelectorMetrics tags
> > > > 
> > > >  Congratulations, Edoardo!
> > > > 
> > > >  Thanks,
> > > > 
> > > >  Jun (on behalf of the Apache Kafka PMC)
> > > > >>>
> > > > >>
> > > >
> > >
>
>