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

See

[jira] [Created] (KAFKA-14313) Kraft: immediately producing to new topics occasionally returns NOT_LEADER_FOR_PARTITION

Travis Bischel created KAFKA-14313: -- Summary: Kraft: immediately producing to new topics occasionally returns NOT_LEADER_FOR_PARTITION Key: KAFKA-14313 URL: https://issues.apache.org/jira/browse/KAFKA-14313

[jira] [Created] (KAFKA-14312) Kraft + ProducerStateManager: produce requests to new partitions with a non-zero sequence number should be rejected

Travis Bischel created KAFKA-14312: -- Summary: Kraft + ProducerStateManager: produce requests to new partitions with a non-zero sequence number should be rejected Key: KAFKA-14312 URL:

[jira] [Created] (KAFKA-14311) Connect Worker clean shutdown does not cleanly stop connectors/tasks

Greg Harris created KAFKA-14311: --- Summary: Connect Worker clean shutdown does not cleanly stop connectors/tasks Key: KAFKA-14311 URL: https://issues.apache.org/jira/browse/KAFKA-14311 Project: Kafka

Re: [DISCUSS] (continued) KIP-848: The Next Generation of the Consumer Rebalance Protocol

Hi, David, Thanks for the reply. Just one more comment. 80. Since PartitionAssignor.AssignmentMemberSpec uses topic name for both subscribedTopics and targetPartitions, in ConsumerGroupPrepareAssignmentResponse, should Members.SubscribedTopicIds and Members.TopicPartitions.TopicId be topic names

[jira] [Created] (KAFKA-14310) EventQueueTimeMs is incorrent for delayed events

José Armando García Sancio created KAFKA-14310: -- Summary: EventQueueTimeMs is incorrent for delayed events Key: KAFKA-14310 URL: https://issues.apache.org/jira/browse/KAFKA-14310 Project:

RE: [DISCUSS] KIP-731: Record Rate Limiting for Kafka Connect

Bump! On 2021/04/09 18:41:17 Ryanne Dolan wrote: > Hey y'all, I'd like to draw you attention to a new KIP: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-731%3A+Record+Rate+Limiting+for+Kafka+Connect > > Lemme know what you think. Thanks! > > Ryanne >

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

I've updated the KIP with the following changes (the confluence diff is not helpful here since i rearranged some things) * Added ZooKeeperBlockingKRaftMillis metric * Added section on new broker registration JSON * Removed section on MigrationCheck RPC * Added change to UpdateMetadataRequest *

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

See

[jira] [Created] (KAFKA-14309) Kafka Streams upgrade tests do not cover for FK-joins

Lucas Brutschy created KAFKA-14309: -- Summary: Kafka Streams upgrade tests do not cover for FK-joins Key: KAFKA-14309 URL: https://issues.apache.org/jira/browse/KAFKA-14309 Project: Kafka

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

Hi Yash, Thanks for your detailed thoughts. 1. In KAFKA-4107 [1], the primary request is exactly what's proposed in the KIP right now: a way to reset offsets for connectors. Sure, there's an extra step of stopping the connector, but renaming a connector isn't as convenient of an alternative as

Re: [DISCUSS] KIP-876: Time based cluster metadata snapshots

Thanks for your feedback Luke. On Thu, Oct 13, 2022 at 11:58 PM Luke Chen wrote: > The only thing I'd like to point out is the compatibility section. > Since this new config is default to 1 hour, which means if users explicitly > set the config `metadata.log.max.record.bytes.between.snapshots`

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

I realised that I mistook the KPI and didn't realize this wasn't part of the REST API so you can ignore what I previously wrote. On Mon, 17 Oct 2022, 12:18 Matthew Benedict de Detrich, < matthew.dedetr...@aiven.io> wrote: > So my only 2 cents on this KIP is mainly from a REST perspective, i.e.

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

See

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

Thanks Greg! I think sorting results (at least w/r/t pagination) is only valuable if it's part of a formal contract; otherwise, a REST extension wouldn't really be able to take advantage of that behavior without becoming brittle across non-major version changes. I'd opt on the side of leaving it

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

On Fri, Oct 14, 2022, at 11:39, Jun Rao wrote: > Hi, Colin, > > 10. "That all goes away in the new mode, and we just have some code which > analyzes __cluster_metadata and reflects it in 1) updates to ZK and 2) > messages sent out to brokers." > Hmm, I am not sure it's that simple. Some of the

Re: [DISCUSS] (continued) KIP-848: The Next Generation of the Consumer Rebalance Protocol

Hi Magnus, Thanks for your comments. Please find my answers below. 1. Right. RebalanceTimeout is max.poll.interval.ms and it is different from the session timeout. Are there parts in the KIP where this is not clear? Note that the session timeout is now defined on the server side so the client

Supported Kafka/Zookeeper Version with ELK 8.4.3

Hi Kafka Team, Currently we are planning to upgrade ELK 7.16 to 8.4.3 version. In our ecosystem we are using Kafka as middleware which is ingesting data coming from different sources where publisher (Logstash shipper) publishing data in different Kafka Topics and subscriber (Logstash indexer)

Re: [DISCUSS] (continued) KIP-848: The Next Generation of the Consumer Rebalance Protocol

Hi David, kudos on a very well designed KIP, this will make a ton of difference for the maintainability of client implementations and operational aspects of consumer groups! Some comments: 1. Maybe I missed this, but where does max.poll.interval.ms fit into the new protocol? It seems like

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

So my only 2 cents on this KIP is mainly from a REST perspective, i.e. in the KIP you mention that you need to add a new field "state.v2": “STOPPED” due to maintaining backwards compatibility with older brokers. My main qualm here is that putting versioning into JSON field names isn’t typically

Re: [DISCUSS] (continued) KIP-848: The Next Generation of the Consumer Rebalance Protocol

Hi Jun, Thanks for your comments. Please find my answers below. 60. Sure. Let me use a concrete example to illustrate it. Let's assume that KStreams has a member A with a task reading from foo-0 and a member B with a standby task reading from foo-0. As you know, the standby task information for

[jira] [Created] (KAFKA-14308) metadata shell might not need to handle leader change message

Luke Chen created KAFKA-14308: - Summary: metadata shell might not need to handle leader change message Key: KAFKA-14308 URL: https://issues.apache.org/jira/browse/KAFKA-14308 Project: Kafka

Re: Requesting Access to contribute to the wiki.

Hi Snehashis, You should be all set up, now! Thank you for your interest in Apache Kafka! Best, Bruno On 17.10.22 09:22, Snehashis wrote: Hi team, I would like to request contributor access to the project, to be able to write KIPs and assign tickets to me. Wiki ID: snehashisp JIRA ID:

Requesting Access to contribute to the wiki.

Hi team, I would like to request contributor access to the project, to be able to write KIPs and assign tickets to me. Wiki ID: snehashisp JIRA ID: snehashisp Thank you Regards Snehashis