Re: Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

Thanks. One question: for the repartition topic format change, do we want to re-use flag=2, or should we introduce flag=3, and determine when compiling the DSL into the Topology if we want/need to include the timestamp, and if not, use format version=2 to avoid unnecessary overhead?

[jira] [Created] (KAFKA-14889) RemoteLogManager - allow consumer fetch records from remote storage implementation

Luke Chen created KAFKA-14889: - Summary: RemoteLogManager - allow consumer fetch records from remote storage implementation Key: KAFKA-14889 URL: https://issues.apache.org/jira/browse/KAFKA-14889

[jira] [Created] (KAFKA-14888) RemoteLogManager - deleting expired/size breached log segments to remote storage implementation

Luke Chen created KAFKA-14888: - Summary: RemoteLogManager - deleting expired/size breached log segments to remote storage implementation Key: KAFKA-14888 URL: https://issues.apache.org/jira/browse/KAFKA-14888

Fwd: [VOTE] KIP-914 Join Processor Semantics for Versioned Stores

Hi everyone, While wrapping up the implementation for KIP-914, I have discovered that two more DSL processors require semantic updates in the presence of versioned tables: - The table filter processor has an optimization to drop nulls if the previous filtered value is also null. When the

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

See Changes: -- [...truncated 461700 lines...] [2023-04-10T23:19:43.148Z] Gradle Test Run :core:integrationTest > Gradle Test Executor 184 > AuthorizerTest >

[VOTE] KIP-909: DNS Resolution Fallures Should Not Fail the Client

Hey everyone! I'm starting a vote for KIP-909: DNS Resolution Fallures Should Not Fail the Client Please refer to the discussion thread here: https://lists.apache.org/thread/st84zzwnq5m3pkzd1r7jk9lmqdt9m98s Thanks! P

Re: [DISCUSS] KIP-909: Allow clients to rebootstrap DNS lookup failure

Thanks, everyone: I'm starting a vote today. Here's the recap for some of the questions: John: I changed the proposal to throw a non-retriable exception after the timeout elapses. I feel it might be necessary to poison the client after retry expires, as it might indicate a real issue. Ismael:

[jira] [Created] (KAFKA-14887) ZK session timeout can cause broker to shutdown

Ron Dagostino created KAFKA-14887: - Summary: ZK session timeout can cause broker to shutdown Key: KAFKA-14887 URL: https://issues.apache.org/jira/browse/KAFKA-14887 Project: Kafka Issue

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

See Changes: -- [...truncated 548332 lines...] [2023-04-10T19:58:29.468Z] Gradle Test Run :connect:mirror:integrationTest > Gradle Test Executor 132 >

[jira] [Created] (KAFKA-14886) Broker request handler thread pool is full due to single request slowdown

Haoze Wu created KAFKA-14886: Summary: Broker request handler thread pool is full due to single request slowdown Key: KAFKA-14886 URL: https://issues.apache.org/jira/browse/KAFKA-14886 Project: Kafka

[jira] [Created] (KAFKA-14885) Client can connect to broker and broker can not connect zookeeper

zou shengfu created KAFKA-14885: --- Summary: Client can connect to broker and broker can not connect zookeeper Key: KAFKA-14885 URL: https://issues.apache.org/jira/browse/KAFKA-14885 Project: Kafka