Re: [ANNOUNCE] New committer: Lucas Bradstreet

[Tom Bentley]

Congratulations!

On Fri, 17 Feb 2023 at 05:26, Yash Mayya  wrote:

> Congratulations Lucas!
>
> On Fri, Feb 17, 2023 at 3:25 AM Jun Rao  wrote:
>
> > Hi, Everyone,
> >
> > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> Lucas
> > Bradstreet.
> >
> > Lucas has been a long time Kafka contributor since Oct. 2018. He has been
> > extremely valuable for Kafka on both performance and correctness
> > improvements.
> >
> > The following are his performance related contributions.
> >
> > KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates batch
> > iterator which is not used
> > KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
> > KAFKA-9729: avoid readLock in authorizer ACL lookups
> > KAFKA-9039: Optimize ReplicaFetcher fetch path
> > KAFKA-8841: Reduce overhead of ReplicaManager.updateFollowerFetchState
> >
> > The following are his correctness related contributions.
> >
> > KAFKA-13194: LogCleaner may clean past highwatermark
> > KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment
> recovery
> > for epoch 0
> > KAFKA-9137: Fix incorrect FetchSessionCache eviction logic
> >
> > Congratulations, Lucas!
> >
> > Thanks,
> >
> > Jun (on behalf of the Apache Kafka PMC)
> >
>

Re: Requesting permissions to contribute to Apache Kafka.

[Luke Chen]

Hi Jakub,

Your wiki account is all set.

Thank you.
Luke

On Fri, Feb 17, 2023 at 4:23 AM Jakub Miroś 
wrote:

> Hello Everyone :)
>
> According to this guide:
>
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
> Could you give me permissions to contribute to Apache Kafka, please?
> WikiID: spacrocketos
> JiraID: SpacRocket ( I already have permissions, adding just in case )
>
> Thanks,
> Jakub

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Luke Chen]

Hi Chia-Ping,

Thanks for the KIP!

Overall LGTM, just one minor comment:
Could we log warning messages to users when using deprecated MessageReader?

Thank you.
Luke


On Fri, Feb 17, 2023 at 2:04 PM Chia-Ping Tsai  wrote:

> hi Bentley
>
> I have updated the KIP to make RecordReader extend Configurable. PTAL
>

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

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Chia-Ping Tsai]

hi Bentley

I have updated the KIP to make RecordReader extend Configurable. PTAL

Re: [ANNOUNCE] New committer: Lucas Bradstreet

[Yash Mayya]

Congratulations Lucas!

On Fri, Feb 17, 2023 at 3:25 AM Jun Rao  wrote:

> Hi, Everyone,
>
> The PMC of Apache Kafka is pleased to announce a new Kafka committer Lucas
> Bradstreet.
>
> Lucas has been a long time Kafka contributor since Oct. 2018. He has been
> extremely valuable for Kafka on both performance and correctness
> improvements.
>
> The following are his performance related contributions.
>
> KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates batch
> iterator which is not used
> KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
> KAFKA-9729: avoid readLock in authorizer ACL lookups
> KAFKA-9039: Optimize ReplicaFetcher fetch path
> KAFKA-8841: Reduce overhead of ReplicaManager.updateFollowerFetchState
>
> The following are his correctness related contributions.
>
> KAFKA-13194: LogCleaner may clean past highwatermark
> KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment recovery
> for epoch 0
> KAFKA-9137: Fix incorrect FetchSessionCache eviction logic
>
> Congratulations, Lucas!
>
> Thanks,
>
> Jun (on behalf of the Apache Kafka PMC)
>

[jira] [Created] (KAFKA-14729) The kafakConsumer pollForFetches(timer) method takes up a lot of cpu due to the abnormal exit of the heartbeat thread

[RivenSun (Jira)]

RivenSun created KAFKA-14729:


 Summary: The kafakConsumer pollForFetches(timer) method takes up a 
lot of cpu due to the abnormal exit of the heartbeat thread
 Key: KAFKA-14729
 URL: https://issues.apache.org/jira/browse/KAFKA-14729
 Project: Kafka
  Issue Type: Bug
  Components: consumer
Affects Versions: 3.3.2, 3.3.0
Reporter: RivenSun
Assignee: RivenSun
 Attachments: image-2023-02-17-13-15-50-362.png, jstack_highCpu.txt

h2. case situation:

1. The business program occupies a large amount of memory, causing the `run()` 
method of HeartbeatThread of kafkaConsumer to exit abnormally.
{code:java}
2023-02-14 06:55:57.771[][ERROR][AbstractCoordinator:1105][kafka-coor][Consumer 
clientId=consumer-5, 
groupId=asyncmq_local_us_dev-webcachesync_fcd02f8e-4f7e-4829-93ed-e8fa9cdc81f2_dev_VA]
 Heartbeat thread failed due to unexpected error java.lang.OutOfMemoryError: 
Java heap space {code}

2. The finally module of the heartbeat thread ` run()` method only prints the 
log, but does not update the value of `AbstractCoordinator.state`.
3. For kafkaConsumer with the groupRebalance mechanism enabled, in the 
`kafkaConsumer#pollForFetches(timer)` method, pollTimeout may eventually take 
the value `timeToNextHeartbeat(now)`.
4. Since the heartbeat thread has exited, `heartbeatTimer.deadlineMs` will 
never be updated again.
And the `AbstractCoordinator.state` field value will always be {*}STABLE{*},
So the `timeToNextHeartbeat(long now)` method will return 
{color:#FF}0{color}.
0 will be passed to the underlying `networkClient#poll` method.

 

In the end, the user calls the `poll(duration)` method in an endless loop, and 
the `kafkaConsumer#pollForFetches(timer)` method will always return very 
quickly, taking up a lot of cpu.

 
h2. solution:


1. Refer to the note of `MemberState.STABLE` : 
{code:java}
the client has joined and is sending heartbeats.{code}

When the heartbeat thread exits, in `finally` module, we should add code:
{code:java}
state = MemberState.UNJOINED;
closed = true;{code}

2. In the `AbstractCoordinator#timeToNextHeartbeat(now)` method, add a new 
judgment condition: `heartbeatThread.hasFailed()`
{code:java}
if (state.hasNotJoinedGroup() || heartbeatThread.hasFailed())
return Long.MAX_VALUE;
return heartbeat.timeToNextHeartbeat(now);{code}
 



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

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

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

Re: [ANNOUNCE] New committer: Lucas Bradstreet

[John Roesler]

Congratulations, Lucas!
-John

On Thu, Feb 16, 2023, at 19:52, Luke Chen wrote:
> Congratulations, Lucas!
>
> Luke
>
> On Fri, Feb 17, 2023 at 8:57 AM Guozhang Wang 
> wrote:
>
>> Congratulations, Lucas!
>>
>> On Thu, Feb 16, 2023 at 3:18 PM Kowshik Prakasam 
>> wrote:
>> >
>> > Congratulations, Lucas!
>> >
>> >
>> > Cheers,
>> > Kowshik
>> >
>> > On Thu, Feb 16, 2023, 2:07 PM Justine Olshan
>> 
>> > wrote:
>> >
>> > > Congratulations Lucas!
>> > >
>> > > Thanks for your mentorship on some of my KIPs as well :)
>> > >
>> > > On Thu, Feb 16, 2023 at 1:56 PM Jun Rao 
>> wrote:
>> > >
>> > > > Hi, Everyone,
>> > > >
>> > > > The PMC of Apache Kafka is pleased to announce a new Kafka committer
>> > > Lucas
>> > > > Bradstreet.
>> > > >
>> > > > Lucas has been a long time Kafka contributor since Oct. 2018. He has
>> been
>> > > > extremely valuable for Kafka on both performance and correctness
>> > > > improvements.
>> > > >
>> > > > The following are his performance related contributions.
>> > > >
>> > > > KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates
>> batch
>> > > > iterator which is not used
>> > > > KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
>> > > > KAFKA-9729: avoid readLock in authorizer ACL lookups
>> > > > KAFKA-9039: Optimize ReplicaFetcher fetch path
>> > > > KAFKA-8841: Reduce overhead of
>> ReplicaManager.updateFollowerFetchState
>> > > >
>> > > > The following are his correctness related contributions.
>> > > >
>> > > > KAFKA-13194: LogCleaner may clean past highwatermark
>> > > > KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment
>> > > recovery
>> > > > for epoch 0
>> > > > KAFKA-9137: Fix incorrect FetchSessionCache eviction logic
>> > > >
>> > > > Congratulations, Lucas!
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Jun (on behalf of the Apache Kafka PMC)
>> > > >
>> > >
>>

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.3 #155

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 501003 lines...]
[2023-02-17T01:54:04.719Z] 
[2023-02-17T01:54:04.719Z] DeleteRecordsRequestTest > 
testErrorWhenDeletingRecordsWithInvalidTopic(String) > 
kafka.server.DeleteRecordsRequestTest.testErrorWhenDeletingRecordsWithInvalidTopic(String)[2]
 STARTED
[2023-02-17T01:54:06.903Z] 
[2023-02-17T01:54:06.903Z] DeleteRecordsRequestTest > 
testErrorWhenDeletingRecordsWithInvalidTopic(String) > 
kafka.server.DeleteRecordsRequestTest.testErrorWhenDeletingRecordsWithInvalidTopic(String)[2]
 PASSED
[2023-02-17T01:54:06.903Z] 
[2023-02-17T01:54:06.903Z] DeleteTopicsRequestWithDeletionDisabledTest > 
testDeleteRecordsRequest() STARTED
[2023-02-17T01:54:08.106Z] 
[2023-02-17T01:54:08.106Z] DeleteTopicsRequestWithDeletionDisabledTest > 
testDeleteRecordsRequest() PASSED
[2023-02-17T01:54:08.106Z] 
[2023-02-17T01:54:08.106Z] DescribeQuorumRequestTest > testDescribeQuorum() > 
kafka.server.DescribeQuorumRequestTest.testDescribeQuorum()[1] STARTED
[2023-02-17T01:54:09.306Z] 
[2023-02-17T01:54:09.306Z] DescribeQuorumRequestTest > testDescribeQuorum() > 
kafka.server.DescribeQuorumRequestTest.testDescribeQuorum()[1] PASSED
[2023-02-17T01:54:09.306Z] 
[2023-02-17T01:54:09.306Z] DescribeQuorumRequestTest > 
testDescribeQuorumNotSupportedByZkBrokers() > 
kafka.server.DescribeQuorumRequestTest.testDescribeQuorumNotSupportedByZkBrokers()[1]
 STARTED
[2023-02-17T01:54:10.522Z] 
[2023-02-17T01:54:10.522Z] DescribeQuorumRequestTest > 
testDescribeQuorumNotSupportedByZkBrokers() > 
kafka.server.DescribeQuorumRequestTest.testDescribeQuorumNotSupportedByZkBrokers()[1]
 PASSED
[2023-02-17T01:54:10.522Z] 
[2023-02-17T01:54:10.522Z] DescribeUserScramCredentialsRequestTest > 
testDescribeNotController() STARTED
[2023-02-17T01:54:11.735Z] 
[2023-02-17T01:54:11.735Z] DescribeUserScramCredentialsRequestTest > 
testDescribeNotController() PASSED
[2023-02-17T01:54:11.735Z] 
[2023-02-17T01:54:11.735Z] DescribeUserScramCredentialsRequestTest > 
testUnknownUser() STARTED
[2023-02-17T01:54:14.032Z] 
[2023-02-17T01:54:14.032Z] DescribeUserScramCredentialsRequestTest > 
testUnknownUser() PASSED
[2023-02-17T01:54:14.032Z] 
[2023-02-17T01:54:14.032Z] DescribeUserScramCredentialsRequestTest > 
testDescribeSameUserTwice() STARTED
[2023-02-17T01:54:15.188Z] 
[2023-02-17T01:54:15.188Z] DescribeUserScramCredentialsRequestTest > 
testDescribeSameUserTwice() PASSED
[2023-02-17T01:54:15.188Z] 
[2023-02-17T01:54:15.188Z] DescribeUserScramCredentialsRequestTest > 
testDescribeWithNull() STARTED
[2023-02-17T01:54:17.402Z] 
[2023-02-17T01:54:17.402Z] DescribeUserScramCredentialsRequestTest > 
testDescribeWithNull() PASSED
[2023-02-17T01:54:17.402Z] 
[2023-02-17T01:54:17.402Z] DescribeUserScramCredentialsRequestTest > 
testDescribeNothing() STARTED
[2023-02-17T01:54:19.591Z] 
[2023-02-17T01:54:19.591Z] DescribeUserScramCredentialsRequestTest > 
testDescribeNothing() PASSED
[2023-02-17T01:54:20.830Z] 
[2023-02-17T01:54:20.830Z] DynamicBrokerReconfigurationTest > 
testDefaultTopicConfig() STARTED
[2023-02-17T01:54:20.830Z] 
[2023-02-17T01:54:20.830Z] DynamicBrokerReconfigurationTest > 
testDefaultTopicConfig() SKIPPED
[2023-02-17T01:54:20.830Z] 
[2023-02-17T01:54:20.830Z] DynamicBrokerReconfigurationTest > 
testMetricsReporterUpdate() STARTED
[2023-02-17T01:54:20.830Z] 
[2023-02-17T01:54:20.830Z] DynamicBrokerReconfigurationTest > 
testMetricsReporterUpdate() SKIPPED
[2023-02-17T01:54:21.940Z] 
[2023-02-17T01:54:21.940Z] DynamicBrokerReconfigurationTest > 
testAdvertisedListenerUpdate() STARTED
[2023-02-17T01:54:33.306Z] 
[2023-02-17T01:54:33.306Z] DynamicBrokerReconfigurationTest > 
testAdvertisedListenerUpdate() PASSED
[2023-02-17T01:54:34.343Z] 
[2023-02-17T01:54:34.343Z] DynamicBrokerReconfigurationTest > 
testConsecutiveConfigChange(String) > 
kafka.server.DynamicBrokerReconfigurationTest.testConsecutiveConfigChange(String)[1]
 STARTED
[2023-02-17T01:54:39.410Z] 
[2023-02-17T01:54:39.410Z] DynamicBrokerReconfigurationTest > 
testConsecutiveConfigChange(String) > 
kafka.server.DynamicBrokerReconfigurationTest.testConsecutiveConfigChange(String)[1]
 PASSED
[2023-02-17T01:54:40.395Z] 
[2023-02-17T01:54:40.395Z] DynamicBrokerReconfigurationTest > 
testConsecutiveConfigChange(String) > 
kafka.server.DynamicBrokerReconfigurationTest.testConsecutiveConfigChange(String)[2]
 STARTED
[2023-02-17T01:54:44.259Z] 
[2023-02-17T01:54:44.259Z] DynamicBrokerReconfigurationTest > 
testConsecutiveConfigChange(String) > 
kafka.server.DynamicBrokerReconfigurationTest.testConsecutiveConfigChange(String)[2]
 PASSED
[2023-02-17T01:54:44.259Z] 
[2023-02-17T01:54:44.259Z] DynamicBrokerReconfigurationTest > 
testThreadPoolResize() STARTED
[2023-02-17T01:54:59.798Z] 
[2023-02-17T01:54:59.798Z] DynamicBrokerReconfigurationTest > 
testThreadPoolResize() PASSED
[2023-02-17T01:55:01.004Z] 
[2023-02-17T01:55:01.004Z] 

Re: [ANNOUNCE] New committer: Lucas Bradstreet

[Luke Chen]

Congratulations, Lucas!

Luke

On Fri, Feb 17, 2023 at 8:57 AM Guozhang Wang 
wrote:

> Congratulations, Lucas!
>
> On Thu, Feb 16, 2023 at 3:18 PM Kowshik Prakasam 
> wrote:
> >
> > Congratulations, Lucas!
> >
> >
> > Cheers,
> > Kowshik
> >
> > On Thu, Feb 16, 2023, 2:07 PM Justine Olshan
> 
> > wrote:
> >
> > > Congratulations Lucas!
> > >
> > > Thanks for your mentorship on some of my KIPs as well :)
> > >
> > > On Thu, Feb 16, 2023 at 1:56 PM Jun Rao 
> wrote:
> > >
> > > > Hi, Everyone,
> > > >
> > > > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > > Lucas
> > > > Bradstreet.
> > > >
> > > > Lucas has been a long time Kafka contributor since Oct. 2018. He has
> been
> > > > extremely valuable for Kafka on both performance and correctness
> > > > improvements.
> > > >
> > > > The following are his performance related contributions.
> > > >
> > > > KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates
> batch
> > > > iterator which is not used
> > > > KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
> > > > KAFKA-9729: avoid readLock in authorizer ACL lookups
> > > > KAFKA-9039: Optimize ReplicaFetcher fetch path
> > > > KAFKA-8841: Reduce overhead of
> ReplicaManager.updateFollowerFetchState
> > > >
> > > > The following are his correctness related contributions.
> > > >
> > > > KAFKA-13194: LogCleaner may clean past highwatermark
> > > > KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment
> > > recovery
> > > > for epoch 0
> > > > KAFKA-9137: Fix incorrect FetchSessionCache eviction logic
> > > >
> > > > Congratulations, Lucas!
> > > >
> > > > Thanks,
> > > >
> > > > Jun (on behalf of the Apache Kafka PMC)
> > > >
> > >
>

[jira] [Resolved] (KAFKA-14253) StreamsPartitionAssignor should print the member count in assignment logs

[Guozhang Wang (Jira)]

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

Guozhang Wang resolved KAFKA-14253.
---
Fix Version/s: 3.5.0
   Resolution: Fixed

> StreamsPartitionAssignor should print the member count in assignment logs
> -
>
> Key: KAFKA-14253
> URL: https://issues.apache.org/jira/browse/KAFKA-14253
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Reporter: John Roesler
>Assignee: Christopher Pooya Razavian
>Priority: Minor
>  Labels: newbie, newbie++
> Fix For: 3.5.0
>
>
> Debugging rebalance and assignment issues is harder than it needs to be. One 
> simple thing that can help is to print out information in the logs that users 
> have to compute today.
> For example, the StreamsPartitionAssignor prints two messages that contain 
> the the newline-delimited group membership:
> {code:java}
> [StreamsPartitionAssignor] [...-StreamThread-1] stream-thread 
> [...-StreamThread-1-consumer] All members participating in this rebalance:
> : []
> : []
> : []{code}
> and
> {code:java}
> [StreamsPartitionAssignor] [...-StreamThread-1] stream-thread 
> [...-StreamThread-1-consumer] Assigned tasks [...] including stateful [...] 
> to clients as:
> =[activeTasks: ([...]) standbyTasks: ([...])]
> =[activeTasks: ([...]) standbyTasks: ([...])]
> =[activeTasks: ([...]) standbyTasks: ([...])
> {code}
>  
> In both of these cases, it would be nice to:
>  # Include the number of members in the group (I.e., "15 members 
> participating" and "to 15 clients as")
>  # sort the member ids (to help compare the membership and assignment across 
> rebalances)



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

Re: [ANNOUNCE] New committer: Lucas Bradstreet

[Guozhang Wang]

Congratulations, Lucas!

On Thu, Feb 16, 2023 at 3:18 PM Kowshik Prakasam  wrote:
>
> Congratulations, Lucas!
>
>
> Cheers,
> Kowshik
>
> On Thu, Feb 16, 2023, 2:07 PM Justine Olshan 
> wrote:
>
> > Congratulations Lucas!
> >
> > Thanks for your mentorship on some of my KIPs as well :)
> >
> > On Thu, Feb 16, 2023 at 1:56 PM Jun Rao  wrote:
> >
> > > Hi, Everyone,
> > >
> > > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > Lucas
> > > Bradstreet.
> > >
> > > Lucas has been a long time Kafka contributor since Oct. 2018. He has been
> > > extremely valuable for Kafka on both performance and correctness
> > > improvements.
> > >
> > > The following are his performance related contributions.
> > >
> > > KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates batch
> > > iterator which is not used
> > > KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
> > > KAFKA-9729: avoid readLock in authorizer ACL lookups
> > > KAFKA-9039: Optimize ReplicaFetcher fetch path
> > > KAFKA-8841: Reduce overhead of ReplicaManager.updateFollowerFetchState
> > >
> > > The following are his correctness related contributions.
> > >
> > > KAFKA-13194: LogCleaner may clean past highwatermark
> > > KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment
> > recovery
> > > for epoch 0
> > > KAFKA-9137: Fix incorrect FetchSessionCache eviction logic
> > >
> > > Congratulations, Lucas!
> > >
> > > Thanks,
> > >
> > > Jun (on behalf of the Apache Kafka PMC)
> > >
> >

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

[Apache Jenkins Server]

See 

[jira] [Resolved] (KAFKA-14727) Connect EOS mode should periodically call task commit

[Chris Egerton (Jira)]

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

Chris Egerton resolved KAFKA-14727.
---
Fix Version/s: 3.5.0
   Resolution: Fixed

> Connect EOS mode should periodically call task commit
> -
>
> Key: KAFKA-14727
> URL: https://issues.apache.org/jira/browse/KAFKA-14727
> Project: Kafka
>  Issue Type: Bug
>  Components: KafkaConnect
>Affects Versions: 3.3.0, 3.4.0, 3.3.1, 3.3.2
>Reporter: Greg Harris
>Assignee: Greg Harris
>Priority: Major
> Fix For: 3.5.0
>
>
> In non-EOS mode, there is a background thread which periodically commits 
> offsets for a task. If this thread does not have resources to flush on the 
> framework side (records, or offsets) it still calls the task's commit() 
> method to update the internal state of the task.
> In EOS mode, there is no background thread, and all offset commits are 
> performed on the main task thread in response to sending records to Kafka. 
> This has the effect of only triggering the task's commit() method when there 
> are records to send to Kafka, which is different than non-EOS mode.
> In order to bring the two modes into better alignment, and allow tasks 
> reliant on the non-EOS empty commit() behavior to work in EOS mode 
> out-of-the-box, EOS mode should provide offset commits periodically for tasks 
> which do not produce records.



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

Re: [ANNOUNCE] New committer: Lucas Bradstreet

[Kowshik Prakasam]

Congratulations, Lucas!


Cheers,
Kowshik

On Thu, Feb 16, 2023, 2:07 PM Justine Olshan 
wrote:

> Congratulations Lucas!
>
> Thanks for your mentorship on some of my KIPs as well :)
>
> On Thu, Feb 16, 2023 at 1:56 PM Jun Rao  wrote:
>
> > Hi, Everyone,
> >
> > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> Lucas
> > Bradstreet.
> >
> > Lucas has been a long time Kafka contributor since Oct. 2018. He has been
> > extremely valuable for Kafka on both performance and correctness
> > improvements.
> >
> > The following are his performance related contributions.
> >
> > KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates batch
> > iterator which is not used
> > KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
> > KAFKA-9729: avoid readLock in authorizer ACL lookups
> > KAFKA-9039: Optimize ReplicaFetcher fetch path
> > KAFKA-8841: Reduce overhead of ReplicaManager.updateFollowerFetchState
> >
> > The following are his correctness related contributions.
> >
> > KAFKA-13194: LogCleaner may clean past highwatermark
> > KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment
> recovery
> > for epoch 0
> > KAFKA-9137: Fix incorrect FetchSessionCache eviction logic
> >
> > Congratulations, Lucas!
> >
> > Thanks,
> >
> > Jun (on behalf of the Apache Kafka PMC)
> >
>

Re: [ANNOUNCE] New committer: Lucas Bradstreet

[Justine Olshan]

Congratulations Lucas!

Thanks for your mentorship on some of my KIPs as well :)

On Thu, Feb 16, 2023 at 1:56 PM Jun Rao  wrote:

> Hi, Everyone,
>
> The PMC of Apache Kafka is pleased to announce a new Kafka committer Lucas
> Bradstreet.
>
> Lucas has been a long time Kafka contributor since Oct. 2018. He has been
> extremely valuable for Kafka on both performance and correctness
> improvements.
>
> The following are his performance related contributions.
>
> KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates batch
> iterator which is not used
> KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
> KAFKA-9729: avoid readLock in authorizer ACL lookups
> KAFKA-9039: Optimize ReplicaFetcher fetch path
> KAFKA-8841: Reduce overhead of ReplicaManager.updateFollowerFetchState
>
> The following are his correctness related contributions.
>
> KAFKA-13194: LogCleaner may clean past highwatermark
> KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment recovery
> for epoch 0
> KAFKA-9137: Fix incorrect FetchSessionCache eviction logic
>
> Congratulations, Lucas!
>
> Thanks,
>
> Jun (on behalf of the Apache Kafka PMC)
>

[ANNOUNCE] New committer: Lucas Bradstreet

[Jun Rao]

Hi, Everyone,

The PMC of Apache Kafka is pleased to announce a new Kafka committer Lucas
Bradstreet.

Lucas has been a long time Kafka contributor since Oct. 2018. He has been
extremely valuable for Kafka on both performance and correctness
improvements.

The following are his performance related contributions.

KAFKA-9820: validateMessagesAndAssignOffsetsCompressed allocates batch
iterator which is not used
KAFKA-9685: Solve Set concatenation perf issue in AclAuthorizer
KAFKA-9729: avoid readLock in authorizer ACL lookups
KAFKA-9039: Optimize ReplicaFetcher fetch path
KAFKA-8841: Reduce overhead of ReplicaManager.updateFollowerFetchState

The following are his correctness related contributions.

KAFKA-13194: LogCleaner may clean past highwatermark
KAFKA-10432: LeaderEpochCache is incorrectly recovered on segment recovery
for epoch 0
KAFKA-9137: Fix incorrect FetchSessionCache eviction logic

Congratulations, Lucas!

Thanks,

Jun (on behalf of the Apache Kafka PMC)

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

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

Requesting permissions to contribute to Apache Kafka.

[Jakub Miroś]

Hello Everyone :)

According to this guide:
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
Could you give me permissions to contribute to Apache Kafka, please?
WikiID: spacrocketos
JiraID: SpacRocket ( I already have permissions, adding just in case )

Thanks,
Jakub

Re: [DISCUSS] KIP-898: Modernize Connect plugin discovery

[Greg Harris]

Hey Tom,

Thank you for your comments!

1. I have updated the language in the KIP and added relevant links.

2. The `plugin.path.discovery` name was intended to communicate that it
controlled the interpretation of the `plugin.path` configuration, but I can
see how that can be confusing.
I suppose the `discovery` mechanism does not really have anything to do
with the `path` itself. If in the future we have an alternative way to give
Connect plugins that doesn't use the `plugin.path`, that mechanism may
still want to use the `discovery` parameter to control it's behavior, and
`plugin.path.discovery` would be a poor name in that situation.
I'll update the KIP to `plugin.discovery`, as `policy` is already used to
describe a pluggable function for override policies; I do not expect that
this mechanism will be made pluggable, as it's part of the plugin
infrastructure itself.

3. I agree that it would be undesirable for someone to drop down to
ONLY_SCAN and then forget about it.
We'll obviously do our due-diligence for error-handling for this feature,
but there's always a risk that the HYBRID modes cause worse behavior than
ONLY_SCAN. I think I'd rather risk operators forgetting to go back to
HYBRID_WARN than require them to wait for an upstream patch to this feature.
But to make it marginally less likely that an operator will forget, I'll
add a static warn to ONLY_SCAN mode that advises the operator to change to
HYBRID_WARN. I'll also remove the "silence warnings" comment from the KIP.

4. I have not worked with sealed jars before, so I'm not sure of the
behavior exactly. But based on the documentation I could find, I don't
expect it to be a problem.
Jar sealing appears to pertain to classes and not resources, and the
ServiceLoader manifest files are resources. Because we are not generating
or mutating any classes, there should not be any impact on the sealing
mechanisms.

However, your comment certainly pertains to cryptographically signed JARs.
If we would modify the JARs themselves, we would certainly invalidate any
cryptographic signatures, and may cause a verification failure during
worker startup.
That is why the manifest generation script only modifies JAR files when no
alternative is present (single-jar-plugins), and prefers to generate shim
jars as you described.
As an alternative, we could consider _not_ migrating single-jar-plugins,
but I think that's more confusing than a script which manipulates code
artifacts causing a signature failure :)
For operators which do use signature verification and the migration script,
they can workaround this by enclosing their single-jar plugins in a
containing directory, and then the script will generate a new jar instead
of mutating the source jar.

Thanks!
Greg Harris

On Thu, Feb 16, 2023 at 3:53 AM Tom Bentley  wrote:

> Hi Greg,
>
> Thanks for the KIP. Overall I think using service loading would be a
> worthwhile improvement.
>
> 1. "Both of these are well-established Java interfaces for which public
> documentation should be readily available." I see no harm in adding a well
> chosen link or two just to save  readers unfamiliar with service loading
> from having to search for documentation.
>
> 2. "plugin.path.discovery" is a bit of an odd name, since it's not
> discovering plugin _paths_, rather it's discovering plugins. So perhaps
> plugin.discovery, or plugin.discovery.policy would be a better name.
>
> 3. I wondered if we really needed "ONLY_SCAN". It seems like the sort of
> thing where someone silences the warnings then forgets about it until one
> day they (or worse, someone else) gets the pleasure of upgrading and
> finding they can't find their plugins. I guess the proposed roll out, over
> multiple major releases, makes this less likely. Non-the-less, logged
> warnings seem like a small price to pay overall, and would make it harder
> for users to ignore the problem. We should be encouraging users to use the
> migration script to silence warnings and adopt SERVICE_LOAD. That way they
> get the benefits sooner than Kafka 5.0.
>
> 4. As described, connect-plugin-path.sh can modify jar files in-place. Have
> you tested/considered whether this will work for sealed jars? I know
> they're not common, but they are part of the Java platform so we can't rule
> out that they're being used. I _think_ service loading should still work
> even if you wrote a new shim jar file which just contained the service
> files needed for loading (alongside the original unmodified jar containing
> the plugins); if that's right then there's no need to actually modify
> existing jars.
>
> Thanks again,
>
> Tom
>
> On Wed, 8 Feb 2023 at 21:45, Chris Egerton 
> wrote:
>
> > Hi Greg,
> >
> > Thanks for the updates. This is looking great. A few minor questions:
> >
> > 1. The description for the list command in the plugin path CLI states
> that
> > it'll show "Whether the class is discoverable via scanning". Are there
> any
> > cases where a plugin found by the CLI won't be 

[jira] [Resolved] (KAFKA-14565) Interceptor Resource Leak

[Chris Egerton (Jira)]

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

Chris Egerton resolved KAFKA-14565.
---
Resolution: Fixed

> Interceptor Resource Leak
> -
>
> Key: KAFKA-14565
> URL: https://issues.apache.org/jira/browse/KAFKA-14565
> Project: Kafka
>  Issue Type: Improvement
>  Components: clients
>Reporter: Terry Beard
>Assignee: Terry Beard
>Priority: Major
> Fix For: 3.5.0
>
>
> The Consumer and Producer interceptor interfaces and their corresponding 
> Kafka Consumer and Producer constructors do not adequately support cleanup of 
> underlying interceptor resources. 
> Currently within the Kafka Consumer and Kafka Producer constructors,  the 
> *AbstractConfig.getConfiguredInstances()*  is delegated responsibility for 
> both creating and configuring each interceptor listed in the 
> interceptor.classes property and returns a configured  
> *List>* interceptors.
> This dual responsibility for both creation and configuration is problematic 
> when it involves multiple interceptors where at least one interceptor's 
> configure method implementation creates and/or depends on objects which 
> creates threads, connections or other resources which requires clean up and 
> the subsequent interceptor's configure method raises a runtime exception.  
> This raising of the runtime exception produces a resource leakage in the 
> first interceptor as the interceptor container i.e. 
> ConsumerInterceptors/ProducerInterceptors is never created and therefore the 
> first interceptor's and really any interceptor's close method are never 
> called.  
> To help ensure the respective container interceptors are able to invoke their 
> respective interceptor close methods for proper resource clean up, I propose 
> two approaches:
> +*PROPOSAL 1*+
> Define a default *open* or *configureWithResources()* or *acquireResources()* 
>  method with no implementation and check exception on the respective 
> Consumer/Producer interceptor interfaces.  This method as a part the 
> interceptor life cycle management will be responsible for creating threads 
> and/or objects which utilizes threads, connections or other resource which 
> requires clean up.  Additionally, this default method enables implementation 
> optionality as it's empty default behavior means it will do nothing when 
> unimplemented mitigating backwards compatibility impact to exiting 
> interceptors.  Finally, the Kafka Consumer/Producer Interceptor containers 
> will implement a corresponding *maybeOpen* or *maybeConfigureWithResources* 
> or *maybeAcquireResources* method which also throws a checked exception. 
> See below code excerpt for the Consumer/Producer constructor:
> {code:java}
> List> interceptorList = (List) 
> config.getConfiguredInstances(
> ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG,
> ConsumerInterceptor.class,
> Collections.singletonMap(ConsumerConfig.CLIENT_ID_CONFIG, clientId));
> this.interceptors = new ConsumerInterceptors<>(interceptorList);
> this.interceptors.maybeConfigureWithResources();
>  {code}
> +*PROPOSAL 2*+
> To avoid changing any public interfaces and the subsequent KIP process, we can
>  * Create a class which inherits or wraps AbstractConfig that contains a new 
> method which will return a ConfiguredInstanceResult class.  This 
> ConfiguredInstanceResult  class will contain an optional list of successfully 
> created interceptors and/or exception which occurred while calling each 
> Interceptor::configure.  Additionally, it will contain a helper method to 
> rethrow an exception as well as a method which returns the underlying 
> exception.  The caller is expected to handle the exception and perform clean 
> up e.g. call  Interceptor::close  on each interceptor in the list provided by 
> the ConfiguredInstanceResult class.
>  * Automatically invoke {{close}} on any {{Closeable}} or {{AutoCloseable}} 
> instances if/when a failure occurs
>  * Add a new overloaded {{getConfiguredInstance}} / 
> {{getConfiguredInstances}} variant that allows users to specify whether 
> already-instantiated classes should be closed or not when a failure occurs
>  * Add a new exception type to the public API that includes a list of all of 
> the successfully-instantiated (and/or successfully-configured) instances 
> before the error was encountered so that callers can choose how to handle the 
> failure however they want (and possibly so that instantiation/configuration 
> can be attempted on every class before throwing the exception)
>  
>  
>  



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

[jira] [Created] (KAFKA-14728) Remove 'spotlessScalaCheck' task (out of Jenkinsfile)

[Jira]

Dejan Stojadinović created KAFKA-14728:
--

 Summary: Remove 'spotlessScalaCheck' task (out of Jenkinsfile)
 Key: KAFKA-14728
 URL: https://issues.apache.org/jira/browse/KAFKA-14728
 Project: Kafka
  Issue Type: Improvement
  Components: build
Reporter: Dejan Stojadinović
Assignee: Dejan Stojadinović


*Note*: this ticket blocks Gradle major version upgrade (_*7 -->> 8*_): 
KAFKA-14680

*Rationale:*
* build works fine in trunk with Gradle 7.6 and spotless gradle plugin 6.13.0 
for all currently used JDK versions (that is: JDK 8 / JDK 11 / JDK 17)
* however, recent spotless gradle plugin versions (6.14.\+) support only JDK 
11\+ versions: 
https://github.com/diffplug/spotless/blob/main/plugin-gradle/CHANGES.md#6140---2023-01-26
 
* given a fact that Kafka still needs to support JDK 8 builds (until Kafka 
version 4.0) it is reasonable to simply remove spotless checks out of 
Jenkinsfile (and re-introduce them when the time comes).

For even more details see GitHub discussion here: 
https://github.com/apache/kafka/pull/13205#issuecomment-1431575644

Note: spotless plugin configuration in build.gradle is out of this ticket scope.



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

Re: [DISCUSS] KIP-899: Allow clients to rebootstrap

[Chris Egerton]

Hi Ivan,

I'm not very familiar with the clients side of things but the proposal
seems reasonable.

I like the flexibility of the "metadata.recovery.strategy" property as a
string instead of, e.g., a "rebootstrap.enabled" boolean. We may want to
adapt a different approach in the future, like the background thread
mentioned in the rejected alternatives section.

I also like handling this via configuration property instead of adding a
Java-level API or suggesting that users re-instantiate their clients since
we may want to enable this new behavior by default in the future, and it
also reduces the level of effort required for users to benefit from this
improvement.

One question I have--that may have an obvious answer to anyone more
familiar with client internals--is under which conditions we will determine
a rebootstrap is appropriate. Taking the admin client as an example, the "
default.api.timeout.ms" property gives us a limit on the time an operation
will be allowed to take before it completes or fails (with optional
per-request overrides in the various *Options classes), and the "
request.timeout.ms" property gives us a limit on the time each request
issued for that operation will be allowed to take before it completes, is
retried, or causes the operation to fail (if no more retries can be
performed). If all of the known servers (i.e., bootstrap servers for the
first operation, or discovered brokers if bootstrapping has already been
completed) are unavailable, the admin client will keep (re)trying to fetch
metadata until the API timeout is exhausted, issuing multiple requests to
the same server if necessary. When would a re-bootstrapping occur here?
Ideally we could find some approach that minimizes false positives (where a
re-bootstrapping is performed even though the current set of known brokers
is only temporarily unavailable, as opposed to permanently moved). Of
course, given the opt-in nature of the re-bootstrapping feature, we can
always shoot for "good enough" on that front, but, it'd be nice to
understand some of the potential pitfalls of enabling it.

Following up on the above, would we cache the need to perform a
re-bootstrap across separate operations? For example, if I try to describe
a cluster, then a re-bootstrapping takes place and fails, and then I try to
describe the cluster a second time. With that second attempt, would we
immediately resort to the bootstrap servers for any initial metadata
updates, or would we still try to go through the last-known set of brokers
first?

Cheers,

Chris

On Mon, Feb 6, 2023 at 4:32 AM Ivan Yurchenko 
wrote:

> Hi!
>
> There seems to be not much more discussion going, so I'm planning to start
> the vote in a couple of days.
>
> Thanks,
>
> Ivan
>
> On Wed, 18 Jan 2023 at 12:06, Ivan Yurchenko 
> wrote:
>
> > Hello!
> > I would like to start the discussion thread on KIP-899: Allow clients to
> > rebootstrap.
> > This KIP proposes to allow Kafka clients to repeat the bootstrap process
> > when fetching metadata if none of the known nodes are available.
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-899%3A+Allow+clients+to+rebootstrap
> >
> > A question right away: should we eventually change the default behavior
> or
> > it can remain configurable "forever"? The latter is proposed in the KIP.
> >
> > Thank you!
> >
> > Ivan
> >
> >
> >
>

[jira] [Created] (KAFKA-14727) Connect EOS mode should periodically call task commit

[Greg Harris (Jira)]

Greg Harris created KAFKA-14727:
---

 Summary: Connect EOS mode should periodically call task commit
 Key: KAFKA-14727
 URL: https://issues.apache.org/jira/browse/KAFKA-14727
 Project: Kafka
  Issue Type: Bug
  Components: KafkaConnect
Affects Versions: 3.4.0
Reporter: Greg Harris
Assignee: Greg Harris


In non-EOS mode, there is a background thread which periodically commits 
offsets for a task. If this thread does not have resources to flush on the 
framework side (records, or offsets) it still calls the task's commit() method 
to update the internal state of the task.

In EOS mode, there is no background thread, and all offset commits are 
performed on the main task thread in response to sending records to Kafka. This 
has the effect of only triggering the task's commit() method when there are 
records to send to Kafka, which is different than non-EOS mode.

In order to bring the two modes into better alignment, and allow tasks reliant 
on the non-EOS empty commit() behavior to work in EOS mode out-of-the-box, EOS 
mode should provide offset commits periodically for tasks which do not produce 
records.



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

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1590

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 532838 lines...]
[2023-02-16T16:30:58.274Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > UpdateFeaturesTest > 
testShouldFailRequestWhenDowngradeToHigherVersionLevelIsAttempted() STARTED
[2023-02-16T16:31:00.044Z] 
[2023-02-16T16:31:00.044Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > UpdateFeaturesTest > 
testShouldFailRequestWhenDowngradeToHigherVersionLevelIsAttempted() PASSED
[2023-02-16T16:31:00.044Z] 
[2023-02-16T16:31:00.044Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > UpdateFeaturesTest > 
testSuccessfulFeatureUpgradeAndWithNoExistingFinalizedFeatures() STARTED
[2023-02-16T16:31:01.738Z] 
[2023-02-16T16:31:01.738Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > UpdateFeaturesTest > 
testSuccessfulFeatureUpgradeAndWithNoExistingFinalizedFeatures() PASSED
[2023-02-16T16:31:01.738Z] 
[2023-02-16T16:31:01.738Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > UpdateFeaturesTest > testSuccessfulFeatureUpgradeAndDowngrade() 
STARTED
[2023-02-16T16:31:03.509Z] 
[2023-02-16T16:31:03.509Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > UpdateFeaturesTest > testSuccessfulFeatureUpgradeAndDowngrade() 
PASSED
[2023-02-16T16:31:03.509Z] 
[2023-02-16T16:31:03.509Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
shouldSurviveFastLeaderChange() STARTED
[2023-02-16T16:31:11.997Z] 
[2023-02-16T16:31:11.997Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
shouldSurviveFastLeaderChange() PASSED
[2023-02-16T16:31:11.997Z] 
[2023-02-16T16:31:11.997Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
offsetsShouldNotGoBackwards() STARTED
[2023-02-16T16:32:20.314Z] 
[2023-02-16T16:32:20.314Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
offsetsShouldNotGoBackwards() PASSED
[2023-02-16T16:32:20.314Z] 
[2023-02-16T16:32:20.314Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
shouldFollowLeaderEpochBasicWorkflow() STARTED
[2023-02-16T16:32:21.261Z] 
[2023-02-16T16:32:21.261Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
shouldFollowLeaderEpochBasicWorkflow() PASSED
[2023-02-16T16:32:21.261Z] 
[2023-02-16T16:32:21.261Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
shouldNotAllowDivergentLogs() STARTED
[2023-02-16T16:32:25.044Z] 
[2023-02-16T16:32:25.044Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
shouldNotAllowDivergentLogs() PASSED
[2023-02-16T16:32:25.044Z] 
[2023-02-16T16:32:25.044Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
logsShouldNotDivergeOnUncleanLeaderElections() STARTED
[2023-02-16T16:32:30.917Z] 
[2023-02-16T16:32:30.917Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > EpochDrivenReplicationProtocolAcceptanceTest > 
logsShouldNotDivergeOnUncleanLeaderElections() PASSED
[2023-02-16T16:32:30.917Z] 
[2023-02-16T16:32:30.917Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > LeaderEpochIntegrationTest > 
shouldIncreaseLeaderEpochBetweenLeaderRestarts() STARTED
[2023-02-16T16:32:32.687Z] 
[2023-02-16T16:32:32.687Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > LeaderEpochIntegrationTest > 
shouldIncreaseLeaderEpochBetweenLeaderRestarts() PASSED
[2023-02-16T16:32:32.687Z] 
[2023-02-16T16:32:32.687Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > LeaderEpochIntegrationTest > 
shouldAddCurrentLeaderEpochToMessagesAsTheyAreWrittenToLeader() STARTED
[2023-02-16T16:32:36.221Z] 
[2023-02-16T16:32:36.221Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > LeaderEpochIntegrationTest > 
shouldAddCurrentLeaderEpochToMessagesAsTheyAreWrittenToLeader() PASSED
[2023-02-16T16:32:36.221Z] 
[2023-02-16T16:32:36.221Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > LeaderEpochIntegrationTest > 
shouldSendLeaderEpochRequestAndGetAResponse() STARTED
[2023-02-16T16:32:37.168Z] 
[2023-02-16T16:32:37.168Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > LeaderEpochIntegrationTest > 
shouldSendLeaderEpochRequestAndGetAResponse() PASSED
[2023-02-16T16:32:37.168Z] 
[2023-02-16T16:32:37.168Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 178 > ReplicationUtilsTest > 

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Chia-Ping Tsai]

> 3. On the matter of configure(): While it doesn't add any functionality, it
> would be more consistent with other plugins if this interface extended
> Configurable, and the InputStream was then passed via some other method
> (`readFrom(InputStream)` perhaps). If nothing else it would make it harder
> to overlook this interface when making changes which apply to all plugins.
> To be honest, I'm not entirely convinced myself, but I thought we should at
> least consider it and add it to the rejected alternatives if we decide
> against it.

Make sense. How about moving the `InputStream` from `configure` to 
`readRecord`? By that change, the `RecordReader` can be a subinterface of 
`Configurable`.

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Chia-Ping Tsai]

On 2023/02/16 11:26:04 Federico Valeri wrote:
> Hi Chia-Ping, thanks for updating the KIP.
> 
> I would only add that we plan to remove the old trait in the next
> major release. I think it's better to be explicit about this.

sure. I have added this description to doc about deprecation.

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Tom Bentley]

Hi Chia-Ping,

Thanks for the KIP. I have just a few minor comments:

1. The Javadoc for the new interface says "an `InputStream` received via
`init`" but the interface doesn't have an init() method. I guess you meant
configure()?
2. The Javadoc should mention the need for implementations to have a public
nullary constructor.
3. On the matter of configure(): While it doesn't add any functionality, it
would be more consistent with other plugins if this interface extended
Configurable, and the InputStream was then passed via some other method
(`readFrom(InputStream)` perhaps). If nothing else it would make it harder
to overlook this interface when making changes which apply to all plugins.
To be honest, I'm not entirely convinced myself, but I thought we should at
least consider it and add it to the rejected alternatives if we decide
against it.

Thanks again,

Tom


On Thu, 16 Feb 2023 at 11:36, Federico Valeri  wrote:

> Hi Chia-Ping, thanks for updating the KIP.
>
> I would only add that we plan to remove the old trait in the next
> major release. I think it's better to be explicit about this.
>
> On Thu, Feb 16, 2023 at 11:34 AM Chia-Ping Tsai 
> wrote:
> >
> > Dear all,
> >
> > I have updated the KIP to address comments. PTAL
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158866569
>
>

[VOTE] KIP-900: KRaft kafka-storage.sh API additions to support SCRAM for Kafka Brokers

[Proven Provenzano]

Hi,

I'd like to start the vote on KIP-900: KRaft kafka-storage.sh API additions
to support SCRAM for Kafka Brokers.

The KIP is here: KIP-900


The Original discuss thread is here: KIP-900-DISCUSS


Please take a look and vote if you can.

Thank you
-- 
--Proven

Re: Kafka design docs

[Arun Raju]

Thank you, Like.

On Wed, Feb 15, 2023, 10:33 PM Luke Chen  wrote:

> Hi Arun,
>
> The official doc should be good enough:
> https://kafka.apache.org/documentation/#design
> For detailed design doc, you can check the Kafka Improvement Proposals:
>
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
>
> Thank you
> Luke
>
> On Thu, Feb 16, 2023 at 7:27 AM Arun Raju  wrote:
>
> > Hi All,
> >
> > Just trying to understand if there are documents relating to high-level
> and
> > low-level design that I can use to understand overall architecture.
> Please
> > let me know.
> >
> > Arun
> >
>

Re: [DISCUSS] KIP-898: Modernize Connect plugin discovery

[Tom Bentley]

Hi Greg,

Thanks for the KIP. Overall I think using service loading would be a
worthwhile improvement.

1. "Both of these are well-established Java interfaces for which public
documentation should be readily available." I see no harm in adding a well
chosen link or two just to save  readers unfamiliar with service loading
from having to search for documentation.

2. "plugin.path.discovery" is a bit of an odd name, since it's not
discovering plugin _paths_, rather it's discovering plugins. So perhaps
plugin.discovery, or plugin.discovery.policy would be a better name.

3. I wondered if we really needed "ONLY_SCAN". It seems like the sort of
thing where someone silences the warnings then forgets about it until one
day they (or worse, someone else) gets the pleasure of upgrading and
finding they can't find their plugins. I guess the proposed roll out, over
multiple major releases, makes this less likely. Non-the-less, logged
warnings seem like a small price to pay overall, and would make it harder
for users to ignore the problem. We should be encouraging users to use the
migration script to silence warnings and adopt SERVICE_LOAD. That way they
get the benefits sooner than Kafka 5.0.

4. As described, connect-plugin-path.sh can modify jar files in-place. Have
you tested/considered whether this will work for sealed jars? I know
they're not common, but they are part of the Java platform so we can't rule
out that they're being used. I _think_ service loading should still work
even if you wrote a new shim jar file which just contained the service
files needed for loading (alongside the original unmodified jar containing
the plugins); if that's right then there's no need to actually modify
existing jars.

Thanks again,

Tom

On Wed, 8 Feb 2023 at 21:45, Chris Egerton  wrote:

> Hi Greg,
>
> Thanks for the updates. This is looking great. A few minor questions:
>
> 1. The description for the list command in the plugin path CLI states that
> it'll show "Whether the class is discoverable via scanning". Are there any
> cases where a plugin found by the CLI won't be discoverable via scanning?
>
> 2. Why are we treating module info files differently than service loader
> manifests (where the latter will be removed for not-found plugins on an
> opt-out basis, but the former are left unmodified no matter what)? Basing
> this off of this sentence in the KIP: "If a plugin declares an
> implementation via a module-info.java which is not loadable, the
> module-info.java will not be modified."; let me know if I'm
> misinterpreting.
>
> Cheers,
>
> Chris
>
> On Tue, Feb 7, 2023 at 4:32 PM Greg Harris 
> wrote:
>
> > Chris,
> >
> > Thanks for the comments!
> >
> > 1. I've updated the script to sync-manifests [--keep-not-found] with your
> > described semantics.
> >
> > 2. I've pushed all of the deprecation decisions to a follow-up KIP that
> can
> > take place after an intervening release.
> > I hope that this feature has a high enough ROI that the direction of the
> > migration is obvious to users even without a formal deprecation notice.
> > I do think that without a formal deprecation notice that the migration
> > scripts may be in use for a long time, particularly for connector
> > implementations which are not receiving active maintenance.
> >
> > 3. Thanks for looking into the ServiceLoader error handling contract.
> > From my inspection of the ServiceLoader implementation, it seems to be
> able
> > to recover from most of the poor packaging scenarios that I'm aware of.
> > I think with or without the deprecation, operators are free to select the
> > ONLY_SCAN mode to work around any errors we don't discover before
> release.
> >
> > Thanks,
> > Greg
> >
> > On Mon, Feb 6, 2023 at 8:44 AM Chris Egerton 
> > wrote:
> >
> > > Hi Greg,
> > >
> > > Thanks for the updates. Unless stated below, I agree with your
> > responses. A
> > > few more thoughts:
> > >
> > > 1. IMO it's not worth it to have separate commands for adding/removing
> > > manifests, mostly because it adds complexity to the tool and might make
> > it
> > > harder for users to understand. I think a single "update-manifests" or
> > > "sync-manifests" command that both adds manifests for found plugins and
> > > removes manifests for unfound plugins by default, with a --keep-unfound
> > > flag to disable removal on an opt-in basis, would make more sense.
> > >
> > > 2. I agree with this point you raise about deprecation: "if we agree
> that
> > > the old mechanism has some sunset date that we just don't know yet, we
> > > should still communicate to users that the sunset date is somewhere in
> > the
> > > future." However, I'm not certain that releasing the features proposed
> in
> > > this KIP alone gives us enough confidence in them to sunset the legacy
> > > plugin loading logic, which is why I was hoping we could have at least
> > one
> > > successful release (preferably even two or three) with this feature in
> > > order to identify potential gaps in the 

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Federico Valeri]

Hi Chia-Ping, thanks for updating the KIP.

I would only add that we plan to remove the old trait in the next
major release. I think it's better to be explicit about this.

On Thu, Feb 16, 2023 at 11:34 AM Chia-Ping Tsai  wrote:
>
> Dear all,
>
> I have updated the KIP to address comments. PTAL
>
>  https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158866569

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

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 435462 lines...]
[2023-02-16T06:03:47.485Z] 
[2023-02-16T06:03:47.485Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testTopicAssignments() STARTED
[2023-02-16T06:03:47.485Z] 
[2023-02-16T06:03:47.485Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testTopicAssignments() PASSED
[2023-02-16T06:03:47.485Z] 
[2023-02-16T06:03:47.485Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testControllerManagementMethods() STARTED
[2023-02-16T06:03:48.496Z] 
[2023-02-16T06:03:48.496Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testControllerManagementMethods() PASSED
[2023-02-16T06:03:48.496Z] 
[2023-02-16T06:03:48.496Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testTopicAssignmentMethods() STARTED
[2023-02-16T06:03:48.496Z] 
[2023-02-16T06:03:48.496Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testTopicAssignmentMethods() PASSED
[2023-02-16T06:03:48.496Z] 
[2023-02-16T06:03:48.496Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testConnectionViaNettyClient() STARTED
[2023-02-16T06:03:49.512Z] 
[2023-02-16T06:03:49.512Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testConnectionViaNettyClient() PASSED
[2023-02-16T06:03:49.512Z] 
[2023-02-16T06:03:49.512Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testPropagateIsrChanges() STARTED
[2023-02-16T06:03:49.512Z] 
[2023-02-16T06:03:49.512Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testPropagateIsrChanges() PASSED
[2023-02-16T06:03:49.512Z] 
[2023-02-16T06:03:49.512Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testControllerEpochMethods() STARTED
[2023-02-16T06:03:50.523Z] 
[2023-02-16T06:03:50.523Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testControllerEpochMethods() PASSED
[2023-02-16T06:03:50.523Z] 
[2023-02-16T06:03:50.523Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testDeleteRecursive() STARTED
[2023-02-16T06:03:50.523Z] 
[2023-02-16T06:03:50.523Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testDeleteRecursive() PASSED
[2023-02-16T06:03:50.523Z] 
[2023-02-16T06:03:50.523Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testGetTopicPartitionStates() STARTED
[2023-02-16T06:03:50.523Z] 
[2023-02-16T06:03:50.523Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testGetTopicPartitionStates() PASSED
[2023-02-16T06:03:50.523Z] 
[2023-02-16T06:03:50.523Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testCreateConfigChangeNotification() STARTED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testCreateConfigChangeNotification() PASSED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testDelegationTokenMethods() STARTED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > KafkaZkClientTest > testDelegationTokenMethods() PASSED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > ZkMigrationClientTest > testUpdateExistingPartitions() STARTED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > ZkMigrationClientTest > testUpdateExistingPartitions() PASSED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > ZkMigrationClientTest > testEmptyWrite() STARTED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > ZkMigrationClientTest > testEmptyWrite() PASSED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > ZkMigrationClientTest > testExistingKRaftControllerClaim() 
STARTED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > ZkMigrationClientTest > testExistingKRaftControllerClaim() PASSED
[2023-02-16T06:03:51.706Z] 
[2023-02-16T06:03:51.706Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 172 > ZkMigrationClientTest 

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Chia-Ping Tsai]

Dear all,

I have updated the KIP to address comments. PTAL

 https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158866569

Re: [DISCUSS] KIP-906 Tools migration guidelines

[Federico Valeri]

On Thu, Feb 16, 2023 at 10:26 AM Luke Chen  wrote:
>
> Hi Federico,
>
> 1. Sounds good.
> I think you should make it clear in the KIP.
>
> We only have one tool with this issue (kafka.tools.StateChangeLogMerger),
> which is tracked in KAFKA-7735
> . This has been broken
> since 2.0 release, so it means that there is not much interest and we
> should simply deprecate.
> It makes me think we're going to abandon this tool since no one is
> interested in it.
> Could we make it clear to mention the broken tool will be fixed in an
> on-going PR, but not included in the scope of this KIP?
>

Sure. That's a good idea.

> 2. For the SPI argument, currently, KIP-641 is still under discussion, not
> passing the votes.
> Do we have any alternative if KIP-641 is rejected?
>

I think the first rejected alternative could also be used for the SPI
argument issue.

> Thank you.
> Luke
>
> On Thu, Feb 16, 2023 at 4:56 PM Federico Valeri 
> wrote:
>
> > Hi Luke, thanks for the feedback.
> >
> > On Thu, Feb 16, 2023 at 9:33 AM Luke Chen  wrote:
> > >
> > > Hi Federico,
> > >
> > > Thanks for the KIP.
> > > It's really helpful to have a general guideline for tools migration so
> > that
> > > contributors and reviewers can be clear what to be expected.
> > >
> > > One question:
> > > In the broker link tool, you said we should directly deprecate it.
> > > But does that mean this tool will keep broken?
> >
> > No, as I already did both migration and fix in the following PR:
> >
> > https://github.com/apache/kafka/pull/13171
> >
> > > Will we fix that during the module movement?
> > >
> >
> > If the above PR is accepted, we will have a deprecated but working
> > version. The general orientation is to remove it in the next major
> > release, because it was broker for a long time and nobody complained.
> >
> > > Thank you.
> > > Luke
> > >
> > > On Thu, Feb 16, 2023 at 4:16 PM Federico Valeri 
> > > wrote:
> > >
> > > > Sorry for the spam. I had some issue with my mail client.
> > > >
> > > > On Wed, Feb 15, 2023 at 3:42 PM Federico Valeri 
> > > > wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > I opened KIP-906 to have some guidelines around tools migration:
> > > > >
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines
> > > > >
> > > > > Let me know if you have any feedback or suggestions.
> > > > >
> > > > > Thanks
> > > > > Fede
> > > >
> >

[jira] [Resolved] (KAFKA-14621) Don't startup in migration mode if an authorizer is enabled

[Luke Chen (Jira)]

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

Luke Chen resolved KAFKA-14621.
---
Fix Version/s: 3.4.0
   Resolution: Done

Close this since this is completed in kafka v3.4.0

 

> Don't startup in migration mode if an authorizer is enabled
> ---
>
> Key: KAFKA-14621
> URL: https://issues.apache.org/jira/browse/KAFKA-14621
> Project: Kafka
>  Issue Type: Sub-task
>Affects Versions: 3.4.0
>Reporter: David Arthur
>Assignee: David Arthur
>Priority: Blocker
> Fix For: 3.4.0
>
>
> In 3.4, we do not yet support migrating ACLs from ZK to KRaft. To avoid 
> potential confusion and security problems, we should just disallow 
> authorizers during the migration.



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

Doubt regarding Kafka Authentication / Authorization

[Viram Shah]

Hi Team,

I have tried multiple ways but couldn't figure out the exact solution to a
problem
I am looking for dynamic user management / access control / new user
addition in Kafka so that we can manage our cluster.
For e.g. whenever a new topic gets created, I want to add a new principal /
username, password and a ACL which gives access to newly added user
permissions to read / write from topic. This new user addition + ACL
addition should happen via code (Java), ACL is still somehow possible but
dynamically new user addition is what is stopping us.

Can someone guide me here?

-- 
Best Regards,
Viram Shah
SDE-II, Increff

www.increff.com
Follow us: LinkedIn  | Youtube
 | Twitter

Read  or contribute
 to Increff reviews on Gartner Peer Insights!

Re: [DISCUSS] KIP-906 Tools migration guidelines

[Luke Chen]

Hi Federico,

1. Sounds good.
I think you should make it clear in the KIP.

We only have one tool with this issue (kafka.tools.StateChangeLogMerger),
which is tracked in KAFKA-7735
. This has been broken
since 2.0 release, so it means that there is not much interest and we
should simply deprecate.
It makes me think we're going to abandon this tool since no one is
interested in it.
Could we make it clear to mention the broken tool will be fixed in an
on-going PR, but not included in the scope of this KIP?

2. For the SPI argument, currently, KIP-641 is still under discussion, not
passing the votes.
Do we have any alternative if KIP-641 is rejected?

Thank you.
Luke

On Thu, Feb 16, 2023 at 4:56 PM Federico Valeri 
wrote:

> Hi Luke, thanks for the feedback.
>
> On Thu, Feb 16, 2023 at 9:33 AM Luke Chen  wrote:
> >
> > Hi Federico,
> >
> > Thanks for the KIP.
> > It's really helpful to have a general guideline for tools migration so
> that
> > contributors and reviewers can be clear what to be expected.
> >
> > One question:
> > In the broker link tool, you said we should directly deprecate it.
> > But does that mean this tool will keep broken?
>
> No, as I already did both migration and fix in the following PR:
>
> https://github.com/apache/kafka/pull/13171
>
> > Will we fix that during the module movement?
> >
>
> If the above PR is accepted, we will have a deprecated but working
> version. The general orientation is to remove it in the next major
> release, because it was broker for a long time and nobody complained.
>
> > Thank you.
> > Luke
> >
> > On Thu, Feb 16, 2023 at 4:16 PM Federico Valeri 
> > wrote:
> >
> > > Sorry for the spam. I had some issue with my mail client.
> > >
> > > On Wed, Feb 15, 2023 at 3:42 PM Federico Valeri 
> > > wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > I opened KIP-906 to have some guidelines around tools migration:
> > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines
> > > >
> > > > Let me know if you have any feedback or suggestions.
> > > >
> > > > Thanks
> > > > Fede
> > >
>

Re: [DISCUSS] KIP-906 Tools migration guidelines

[Federico Valeri]

Hi Luke, thanks for the feedback.

On Thu, Feb 16, 2023 at 9:33 AM Luke Chen  wrote:
>
> Hi Federico,
>
> Thanks for the KIP.
> It's really helpful to have a general guideline for tools migration so that
> contributors and reviewers can be clear what to be expected.
>
> One question:
> In the broker link tool, you said we should directly deprecate it.
> But does that mean this tool will keep broken?

No, as I already did both migration and fix in the following PR:

https://github.com/apache/kafka/pull/13171

> Will we fix that during the module movement?
>

If the above PR is accepted, we will have a deprecated but working
version. The general orientation is to remove it in the next major
release, because it was broker for a long time and nobody complained.

> Thank you.
> Luke
>
> On Thu, Feb 16, 2023 at 4:16 PM Federico Valeri 
> wrote:
>
> > Sorry for the spam. I had some issue with my mail client.
> >
> > On Wed, Feb 15, 2023 at 3:42 PM Federico Valeri 
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > I opened KIP-906 to have some guidelines around tools migration:
> > >
> > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines
> > >
> > > Let me know if you have any feedback or suggestions.
> > >
> > > Thanks
> > > Fede
> >

Re: [DISCUSS] KIP-906 Tools migration guidelines

[Luke Chen]

Hi Federico,

Thanks for the KIP.
It's really helpful to have a general guideline for tools migration so that
contributors and reviewers can be clear what to be expected.

One question:
In the broker link tool, you said we should directly deprecate it.
But does that mean this tool will keep broken?
Will we fix that during the module movement?

Thank you.
Luke

On Thu, Feb 16, 2023 at 4:16 PM Federico Valeri 
wrote:

> Sorry for the spam. I had some issue with my mail client.
>
> On Wed, Feb 15, 2023 at 3:42 PM Federico Valeri 
> wrote:
> >
> > Hi everyone,
> >
> > I opened KIP-906 to have some guidelines around tools migration:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines
> >
> > Let me know if you have any feedback or suggestions.
> >
> > Thanks
> > Fede
>

Re: [DISCUSS] KIP-906 Tools migration guidelines

[Federico Valeri]

Sorry for the spam. I had some issue with my mail client.

On Wed, Feb 15, 2023 at 3:42 PM Federico Valeri  wrote:
>
> Hi everyone,
>
> I opened KIP-906 to have some guidelines around tools migration:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines
>
> Let me know if you have any feedback or suggestions.
>
> Thanks
> Fede

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

[Apache Jenkins Server]

See