Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.0 #139

See

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

See Changes: -- [...truncated 424459 lines...] [2021-09-24T01:29:17.585Z] [INFO] [2021-09-24T01:29:17.585Z] [INFO] --- maven-site-plugin:3.5.1:attach-descriptor

[jira] [Resolved] (KAFKA-13070) LogManager shutdown races with periodic work scheduled by the instance

[ https://issues.apache.org/jira/browse/KAFKA-13070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-13070. - Resolution: Duplicate > LogManager shutdown races with periodic work scheduled by the instance >

[jira] [Resolved] (KAFKA-13315) log layer exception during shutdown that caused an unclean shutdown

[ https://issues.apache.org/jira/browse/KAFKA-13315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-13315. - Fix Version/s: 3.0.1 3.1.0 Resolution: Fixed merged the PR to trunk and 3.0.

Re: [DISCUSS] KIP-768: Extend SASL/OAUTHBEARER with Support for OIDC

Hi Manikumar, On Wed, Aug 25, 2021, at 8:54 PM, Manikumar wrote: > Thanks for the reply, > > Can we also update the KIP about the testing approach? Yes, I've added that as a dedicated section in the KIP:

Re: [DISCUSS] KIP-768: Extend SASL/OAUTHBEARER with Support for OIDC

Hi Jun, On Tue, Sep 21, 2021, at 10:51 AM, Jun Rao wrote: > Hi, Kirk, > > Thanks for the KIP. Does the proposal support reauthentication outlined > in KIP-368? Yes, the existing mechanism for re-authentication is implemented at a higher layer of the code, so we just get it for "free." I've

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

See Changes: -- [...truncated 494953 lines...] [2021-09-23T19:47:06.264Z] > Task :raft:compileTestJava UP-TO-DATE [2021-09-23T19:47:06.264Z] > Task :raft:testClasses

[jira] [Created] (KAFKA-13321) Notify listener of leader change on registration

Jose Armando Garcia Sancio created KAFKA-13321: -- Summary: Notify listener of leader change on registration Key: KAFKA-13321 URL: https://issues.apache.org/jira/browse/KAFKA-13321 Project:

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

See Changes: -- [...truncated 494148 lines...] [2021-09-23T15:33:50.012Z] [2021-09-23T15:33:50.012Z] FetchRequestBetweenDifferentIbpTest > testControllerOldToNewIBP()

[jira] [Created] (KAFKA-13320) Suggestion: SMT support for null key/value should be documented

Ben Ellis created KAFKA-13320: - Summary: Suggestion: SMT support for null key/value should be documented Key: KAFKA-13320 URL: https://issues.apache.org/jira/browse/KAFKA-13320 Project: Kafka

GC pressure of the java client

Hi All, I've been recently profiling the java client and noticed that it produces considerable pressure on GC. My main concern is the consumer as it creates multiple collections during a single poll command: in my test system i have a consumer that polls a topic with 100 partitions and even

[jira] [Resolved] (KAFKA-10544) Convert KTable aggregations to new PAPI

[ https://issues.apache.org/jira/browse/KAFKA-10544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Esteban Quilcate Otoya resolved KAFKA-10544. -- Resolution: Fixed https://github.com/apache/kafka/pull/11316

Re: Building 3.0.0 and Task :connect:signMavenJavaPublication FAILED

Hi, I found a solution! It's -PskipSigning=true and it is in README.md actually (but somehow it was not required in the earlier versions, e.g. 2.8.0): > skipSigning: skips signing of artifacts. The following works nicely! ./gradlew clean releaseTarGz install -PskipSigning=true [1]

Building 3.0.0 and Task :connect:signMavenJavaPublication FAILED

Hi, I've been trying to build the latest version of Kafka 3.0.0 and no joy so far. $ ./gradlew clean releaseTarGz install ... > Configure project : Starting build with version 3.0.0 using Gradle 7.1.1, Java 11 and Scala 2.13.6 > Task :connect:signMavenJavaPublication FAILED FAILURE: Build

Re: [DISCUSS] KIP-774: Deprecate public access to Admin client's *Result constructors

> > I suppose that could be avoided by the use of private constructors and > public static factory methods (different method names means there's no > overloading, so no ambiguity in when signatures need to differ only by > generic type argument). But we'd have to choose names for those static >