RE: Last sprint to finish line: Replace EasyMock/Powermock with Mockito

Hello! This email summarises the current state of Kafka's Mockito migration. The JIRA tickets used to track the progress are https://issues.apache.org/jira/browse/KAFKA-14132 and https://issues.apache.org/jira/browse/KAFKA-14133

[jira] [Resolved] (KAFKA-14363) Add new `group-coordinator` module

[ https://issues.apache.org/jira/browse/KAFKA-14363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jacot resolved KAFKA-14363. - Resolution: Fixed > Add new `group-coordinator` module > -- > >

[jira] [Reopened] (KAFKA-13891) sync group failed with rebalanceInProgress error cause rebalance many rounds in coopeartive

[ https://issues.apache.org/jira/browse/KAFKA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman reopened KAFKA-13891: Reopening – original fix was reverted, we should instead fix this assignor-sid

Re: [VOTE] KIP-866 ZooKeeper to KRaft Migration

Hi David, Looks great. Some questions: I agree with Jun that it would be good to rename metadata.migration.enable to something more zk-specific. Maybe zk.metadata.migration.enable ? SImilarly, for MigrationRecord: can we rename this to ZkMigrationStateRecord? Then change MigrationState -> ZkMi

[jira] [Created] (KAFKA-14370) Properly close ImageWriter objects

Colin McCabe created KAFKA-14370: Summary: Properly close ImageWriter objects Key: KAFKA-14370 URL: https://issues.apache.org/jira/browse/KAFKA-14370 Project: Kafka Issue Type: Bug

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

See

Re: [DISCUSS] KIP-866 ZooKeeper to KRaft Migration

Hi, David, Thanks for the reply. 20/21. Thanks for the explanation. The suggestion sounds good. Could you include that in the doc? 40. metadata.migration.enable: We may do future metadata migrations within KRaft. Could we make the name more specific to ZK migration like zookeeper.metadata.migrat

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

See

Re: [DISCUSS] KIP-866 ZooKeeper to KRaft Migration

Ah, sorry about that, you're right. Since we won't support ZK migrations in combined mode, is this issue avoided? Essentially, we would only set ZkMigrationReady in ApiVersionsResponse if * process.roles=controller * kafka.metadata.migration.enabled=true Also, the following would be an invalid c

[jira] [Created] (KAFKA-14369) Docs - KRAFT controller authentication example

Domenic Bove created KAFKA-14369: Summary: Docs - KRAFT controller authentication example Key: KAFKA-14369 URL: https://issues.apache.org/jira/browse/KAFKA-14369 Project: Kafka Issue Type: Bu

Re: [DISCUSS] KIP-875: First-class offsets support in Kafka Connect

Hi Yash, Good question! This is actually a subtle source of asymmetry in the current proposal. Requests to delete a consumer group with active members will fail, so if there are zombie sink tasks that are still communicating with Kafka, offset reset requests for that connector will also fail. It i

Re: [DISCUSS] KIP-866 ZooKeeper to KRaft Migration

Hi, David, I am not sure that we are fully settled on the following. 20/21. Since separate listeners are optional, it seems that the broker can't distinguish between ApiVersion requests coming from the client or other brokers. This means the clients will get ZkMigrationReady in the ApiVersion res

[VOTE] KIP-866 ZooKeeper to KRaft Migration

Hello everyone, I'd like to start the vote on KIP-866. https://cwiki.apache.org/confluence/display/KAFKA/KIP-866+ZooKeeper+to+KRaft+Migration Thanks! David Arthur

Re: [DISCUSS] KIP-866 ZooKeeper to KRaft Migration

Thanks for the discussion everyone, I'm going to move ahead with the vote for this KIP. -David On Thu, Nov 3, 2022 at 1:20 PM Jun Rao wrote: > > Hi, David, > > Thanks for the reply. > > 20/21 Yes, but separate listeners are optional. It's possible for the nodes > to use a single port for both cl

Re: [DISCUSS] KIP-872: Add Serializer#serializeToByteBuffer() to reduce memory copying

Thanks John! I will consider your opinion, I’ve been busy at work lately. Best, ShunKang John Roesler 于2022年11月6日 周日23:22写道： > Thanks for the reply, ShunKang! > > You’re absolutely right, we should not change the behavior of the existing > method. > > Regarding the new method, I was thinking th

[jira] [Created] (KAFKA-14368) Add an offset write REST API to Kafka Connect

Yash Mayya created KAFKA-14368: -- Summary: Add an offset write REST API to Kafka Connect Key: KAFKA-14368 URL: https://issues.apache.org/jira/browse/KAFKA-14368 Project: Kafka Issue Type: New Fea

Re: [DISCUSS] KIP-875: First-class offsets support in Kafka Connect

Hi Chris, Thanks for the response and the explanations, I think you've answered pretty much all the questions I had meticulously! > if something goes wrong while resetting offsets, there's no > immediate impact--the connector will still be in the STOPPED > state. The REST response for requests

Re: [DISCUSS] KIP-852 Optimize calculation of size for log in remote tier

Hey Jun Thank you for your comments. *1. "RLMM implementor could ensure that listRemoteLogSegments() is fast"* This would be ideal but pragmatically, it is difficult to ensure that listRemoteLogSegments() is fast. This is because of the possibility of a large number of segments (much larger than

[jira] [Created] (KAFKA-14367) Introduce `GroupCoordinator` interface

David Jacot created KAFKA-14367: --- Summary: Introduce `GroupCoordinator` interface Key: KAFKA-14367 URL: https://issues.apache.org/jira/browse/KAFKA-14367 Project: Kafka Issue Type: Sub-task