Re: Subject: [VOTE] 2.2.2 RC2

[Jason Gustafson]

+1 (binding)

Verified release notes and ran through the 2.12 quickstart.

Thanks Randall!

On Thu, Nov 14, 2019 at 8:52 PM Gwen Shapira  wrote:

> +1 (binding)
>
> Thanks Randall. Verified signatures and tests.
>
> On Fri, Oct 25, 2019 at 7:10 AM Randall Hauch  wrote:
> >
> > Hello all, we identified around three dozen bug fixes, including an
> update
> > of a third party dependency, and wanted to release a patch release for
> the
> > Apache Kafka 2.2.0 release.
> >
> > This is the *second* candidate for release of Apache Kafka 2.2.2. (RC1
> did
> > not include a fix for https://issues.apache.org/jira/browse/KAFKA-9053,
> but
> > the fix appeared before RC1 was announced so it was easier to just create
> > RC2.)
> >
> > Check out the release notes for a complete list of the changes in this
> > release candidate:
> > https://home.apache.org/~rhauch/kafka-2.2.2-rc2/RELEASE_NOTES.html
> >
> > *** Please download, test and vote by Wednesday, October 30, 9am PT>
> >
> > Kafka's KEYS file containing PGP keys we use to sign the release:
> > https://kafka.apache.org/KEYS
> >
> > * Release artifacts to be voted upon (source and binary):
> > https://home.apache.org/~rhauch/kafka-2.2.2-rc2/
> >
> > * Maven artifacts to be voted upon:
> > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> >
> > * Javadoc:
> > https://home.apache.org/~rhauch/kafka-2.2.2-rc2/javadoc/
> >
> > * Tag to be voted upon (off 2.2 branch) is the 2.2.2 tag:
> > https://github.com/apache/kafka/releases/tag/2.2.2-rc2
> >
> > * Documentation:
> > https://kafka.apache.org/22/documentation.html
> >
> > * Protocol:
> > https://kafka.apache.org/22/protocol.html
> >
> > * Successful Jenkins builds for the 2.2 branch:
> > Unit/integration tests: https://builds.apache.org/job/kafka-2.2-jdk8/1/
> > System tests:
> > https://jenkins.confluent.io/job/system-test-kafka/job/2.2/216/
> >
> > /**
> >
> > Thanks,
> >
> > Randall Hauch
>

[jira] [Reopened] (KAFKA-9208) Flaky Test SslAdminClientIntegrationTest.testCreatePartitions

[Sophie Blee-Goldman (Jira)]

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

Sophie Blee-Goldman reopened KAFKA-9208:


Note that this test is distinct from the similar flaky test 
AdminClientIntegrationTest.testCreatePartitions, and does not duplicate 
KAFKA-9069

> Flaky Test SslAdminClientIntegrationTest.testCreatePartitions
> -
>
> Key: KAFKA-9208
> URL: https://issues.apache.org/jira/browse/KAFKA-9208
> Project: Kafka
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.4.0
>Reporter: Sophie Blee-Goldman
>Priority: Major
>  Labels: flaky-test
>
> Java 8 build failed on 2.4-targeted PR
> h3. Stacktrace
> java.lang.AssertionError: validateOnly expected:<3> but was:<1> at 
> org.junit.Assert.fail(Assert.java:89) at 
> org.junit.Assert.failNotEquals(Assert.java:835) at 
> org.junit.Assert.assertEquals(Assert.java:647) at 
> kafka.api.AdminClientIntegrationTest$$anonfun$testCreatePartitions$6.apply(AdminClientIntegrationTest.scala:625)
>  at 
> kafka.api.AdminClientIntegrationTest$$anonfun$testCreatePartitions$6.apply(AdminClientIntegrationTest.scala:599)
>  at scala.collection.immutable.List.foreach(List.scala:392) at 
> kafka.api.AdminClientIntegrationTest.testCreatePartitions(AdminClientIntegrationTest.scala:599)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
> at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
> at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:288)
>  at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:282)
>  at java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
> java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (KAFKA-9208) Flaky Test SslAdminClientIntegrationTest.testCreatePartitions

[huxihx (Jira)]

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

huxihx resolved KAFKA-9208.
---
Resolution: Duplicate

> Flaky Test SslAdminClientIntegrationTest.testCreatePartitions
> -
>
> Key: KAFKA-9208
> URL: https://issues.apache.org/jira/browse/KAFKA-9208
> Project: Kafka
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.4.0
>Reporter: Sophie Blee-Goldman
>Priority: Major
>  Labels: flaky-test
>
> Java 8 build failed on 2.4-targeted PR
> h3. Stacktrace
> java.lang.AssertionError: validateOnly expected:<3> but was:<1> at 
> org.junit.Assert.fail(Assert.java:89) at 
> org.junit.Assert.failNotEquals(Assert.java:835) at 
> org.junit.Assert.assertEquals(Assert.java:647) at 
> kafka.api.AdminClientIntegrationTest$$anonfun$testCreatePartitions$6.apply(AdminClientIntegrationTest.scala:625)
>  at 
> kafka.api.AdminClientIntegrationTest$$anonfun$testCreatePartitions$6.apply(AdminClientIntegrationTest.scala:599)
>  at scala.collection.immutable.List.foreach(List.scala:392) at 
> kafka.api.AdminClientIntegrationTest.testCreatePartitions(AdminClientIntegrationTest.scala:599)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
> at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
> at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:288)
>  at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:282)
>  at java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
> java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Build failed in Jenkins: kafka-2.0-jdk8 #300

[Apache Jenkins Server]

See 


Changes:

[rhauch] KAFKA-9051: Prematurely complete source offset read requests for 
stopped


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H48 (ubuntu) in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Deferred wipeout is used...
No credentials specified
Cloning the remote Git repository
Cloning repository https://github.com/apache/kafka.git
 > git init  # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git fetch --tags --progress -- https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/2.0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/2.0^{commit} # timeout=10
Checking out Revision b09b8fa242e97e4be71e1697b75d5410a6754285 
(refs/remotes/origin/2.0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b09b8fa242e97e4be71e1697b75d5410a6754285
Commit message: "KAFKA-9051: Prematurely complete source offset read requests 
for stopped tasks (#7532)"
 > git rev-list --no-walk 76da5a376e9f5d776b98db0f86b34cb147d8 # timeout=10
ERROR: No tool found matching GRADLE_4_8_1_HOME
ERROR: No tool found matching GRADLE_4_8_1_HOME
[kafka-2.0-jdk8] $ /bin/bash -xe /tmp/jenkins7309341385706930940.sh
+ rm -rf 
+ /bin/gradle
/tmp/jenkins7309341385706930940.sh: line 4: /bin/gradle: No such file or 
directory
Build step 'Execute shell' marked build as failure
[FINDBUGS] Collecting findbugs analysis files...
ERROR: No tool found matching GRADLE_4_8_1_HOME
[FINDBUGS] Searching for all files in 
 that match the pattern 
**/build/reports/findbugs/*.xml
[FINDBUGS] No files found. Configuration error?
ERROR: No tool found matching GRADLE_4_8_1_HOME
No credentials specified
ERROR: No tool found matching GRADLE_4_8_1_HOME
 Using GitBlamer to create author and commit information for all 
warnings.
 GIT_COMMIT=b09b8fa242e97e4be71e1697b75d5410a6754285, 
workspace=
[FINDBUGS] Computing warning deltas based on reference build #298
Recording test results
ERROR: No tool found matching GRADLE_4_8_1_HOME
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
ERROR: No tool found matching GRADLE_4_8_1_HOME

Build failed in Jenkins: kafka-2.1-jdk8 #241

[Apache Jenkins Server]

See 


Changes:

[rhauch] KAFKA-9051: Prematurely complete source offset read requests for 
stopped


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H40 (ubuntu xenial) in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Deferred wipeout is used...
No credentials specified
Cloning the remote Git repository
Cloning repository https://github.com/apache/kafka.git
 > git init  # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/2.1^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/2.1^{commit} # timeout=10
Checking out Revision 92769233e209383b7c65f6378ba698f17b056be6 
(refs/remotes/origin/2.1)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 92769233e209383b7c65f6378ba698f17b056be6
Commit message: "KAFKA-9051: Prematurely complete source offset read requests 
for stopped tasks (#7532)"
 > git rev-list --no-walk 0f61981016575eebf7e91e931617f21ee844c5cf # timeout=10
ERROR: No tool found matching GRADLE_4_8_1_HOME
ERROR: No tool found matching GRADLE_4_8_1_HOME
[kafka-2.1-jdk8] $ /bin/bash -xe /tmp/jenkins513672136376389.sh
+ rm -rf 
+ /bin/gradle
/tmp/jenkins513672136376389.sh: line 4: /bin/gradle: No such file or 
directory
Build step 'Execute shell' marked build as failure
[FINDBUGS] Collecting findbugs analysis files...
ERROR: No tool found matching GRADLE_4_8_1_HOME
[FINDBUGS] Searching for all files in 
 that match the pattern 
**/build/reports/findbugs/*.xml
[FINDBUGS] No files found. Configuration error?
ERROR: No tool found matching GRADLE_4_8_1_HOME
No credentials specified
ERROR: No tool found matching GRADLE_4_8_1_HOME
 Using GitBlamer to create author and commit information for all 
warnings.
 GIT_COMMIT=92769233e209383b7c65f6378ba698f17b056be6, 
workspace=
[FINDBUGS] Computing warning deltas based on reference build #230
Recording test results
ERROR: No tool found matching GRADLE_4_8_1_HOME
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
ERROR: No tool found matching GRADLE_4_8_1_HOME
Not sending mail to unregistered user b...@confluent.io
Not sending mail to unregistered user wangg...@gmail.com

Build failed in Jenkins: kafka-trunk-jdk8 #4055

[Apache Jenkins Server]

See 


Changes:

[bill] HOTFIX: safely clear all active state in onPartitionsLost (#7691)


--
[...truncated 2.74 MB...]
org.apache.kafka.streams.TestTopicsTest > testNegativeAdvance STARTED

org.apache.kafka.streams.TestTopicsTest > testNegativeAdvance PASSED

org.apache.kafka.streams.TestTopicsTest > shouldNotAllowToCreateWithNullDriver 
STARTED

org.apache.kafka.streams.TestTopicsTest > shouldNotAllowToCreateWithNullDriver 
PASSED

org.apache.kafka.streams.TestTopicsTest > testDuration STARTED

org.apache.kafka.streams.TestTopicsTest > testDuration PASSED

org.apache.kafka.streams.TestTopicsTest > testOutputToString STARTED

org.apache.kafka.streams.TestTopicsTest > testOutputToString PASSED

org.apache.kafka.streams.TestTopicsTest > testValue STARTED

org.apache.kafka.streams.TestTopicsTest > testValue PASSED

org.apache.kafka.streams.TestTopicsTest > testTimestampAutoAdvance STARTED

org.apache.kafka.streams.TestTopicsTest > testTimestampAutoAdvance PASSED

org.apache.kafka.streams.TestTopicsTest > testOutputWrongSerde STARTED

org.apache.kafka.streams.TestTopicsTest > testOutputWrongSerde PASSED

org.apache.kafka.streams.TestTopicsTest > 
shouldNotAllowToCreateOutputTopicWithNullTopicName STARTED

org.apache.kafka.streams.TestTopicsTest > 
shouldNotAllowToCreateOutputTopicWithNullTopicName PASSED

org.apache.kafka.streams.TestTopicsTest > testWrongSerde STARTED

org.apache.kafka.streams.TestTopicsTest > testWrongSerde PASSED

org.apache.kafka.streams.TestTopicsTest > testKeyValuesToMapWithNull STARTED

org.apache.kafka.streams.TestTopicsTest > testKeyValuesToMapWithNull PASSED

org.apache.kafka.streams.TestTopicsTest > testNonExistingOutputTopic STARTED

org.apache.kafka.streams.TestTopicsTest > testNonExistingOutputTopic PASSED

org.apache.kafka.streams.TestTopicsTest > testMultipleTopics STARTED

org.apache.kafka.streams.TestTopicsTest > testMultipleTopics PASSED

org.apache.kafka.streams.TestTopicsTest > testKeyValueList STARTED

org.apache.kafka.streams.TestTopicsTest > testKeyValueList PASSED

org.apache.kafka.streams.TestTopicsTest > 
shouldNotAllowToCreateOutputWithNullDriver STARTED

org.apache.kafka.streams.TestTopicsTest > 
shouldNotAllowToCreateOutputWithNullDriver PASSED

org.apache.kafka.streams.TestTopicsTest > testValueList STARTED

org.apache.kafka.streams.TestTopicsTest > testValueList PASSED

org.apache.kafka.streams.TestTopicsTest > testRecordList STARTED

org.apache.kafka.streams.TestTopicsTest > testRecordList PASSED

org.apache.kafka.streams.TestTopicsTest > testNonExistingInputTopic STARTED

org.apache.kafka.streams.TestTopicsTest > testNonExistingInputTopic PASSED

org.apache.kafka.streams.TestTopicsTest > testKeyValuesToMap STARTED

org.apache.kafka.streams.TestTopicsTest > testKeyValuesToMap PASSED

org.apache.kafka.streams.TestTopicsTest > testRecordsToList STARTED

org.apache.kafka.streams.TestTopicsTest > testRecordsToList PASSED

org.apache.kafka.streams.TestTopicsTest > testKeyValueListDuration STARTED

org.apache.kafka.streams.TestTopicsTest > testKeyValueListDuration PASSED

org.apache.kafka.streams.TestTopicsTest > testInputToString STARTED

org.apache.kafka.streams.TestTopicsTest > testInputToString PASSED

org.apache.kafka.streams.TestTopicsTest > testTimestamp STARTED

org.apache.kafka.streams.TestTopicsTest > testTimestamp PASSED

org.apache.kafka.streams.TestTopicsTest > testWithHeaders STARTED

org.apache.kafka.streams.TestTopicsTest > testWithHeaders PASSED

org.apache.kafka.streams.TestTopicsTest > testKeyValue STARTED

org.apache.kafka.streams.TestTopicsTest > testKeyValue PASSED

org.apache.kafka.streams.TestTopicsTest > 
shouldNotAllowToCreateTopicWithNullTopicName STARTED

org.apache.kafka.streams.TestTopicsTest > 
shouldNotAllowToCreateTopicWithNullTopicName PASSED

> Task :streams:upgrade-system-tests-0100:processTestResources NO-SOURCE
> Task :streams:upgrade-system-tests-0100:testClasses
> Task :streams:upgrade-system-tests-0100:checkstyleTest
> Task :streams:upgrade-system-tests-0100:spotbugsMain NO-SOURCE
> Task :streams:upgrade-system-tests-0100:test
> Task :streams:upgrade-system-tests-0101:compileJava NO-SOURCE
> Task :streams:upgrade-system-tests-0101:processResources NO-SOURCE
> Task :streams:upgrade-system-tests-0101:classes UP-TO-DATE
> Task :streams:upgrade-system-tests-0101:checkstyleMain NO-SOURCE
> Task :streams:upgrade-system-tests-0101:compileTestJava
> Task :streams:upgrade-system-tests-0101:processTestResources NO-SOURCE
> Task :streams:upgrade-system-tests-0101:testClasses
> Task :streams:upgrade-system-tests-0101:checkstyleTest
> Task :streams:upgrade-system-tests-0101:spotbugsMain NO-SOURCE
> Task :streams:upgrade-system-tests-0101:test
> Task :streams:upgrade-system-tests-0102:compileJava NO-SOURCE
> Task :streams:upgrade-system-tests-0102:processResources NO-SOURCE
> Task 

Build failed in Jenkins: kafka-2.2-jdk8-old #186

[Apache Jenkins Server]

See 


Changes:

[rhauch] KAFKA-9051: Prematurely complete source offset read requests for 
stopped


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H37 (ubuntu xenial) in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Deferred wipeout is used...
No credentials specified
Cloning the remote Git repository
Cloning repository https://github.com/apache/kafka.git
 > git init  # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/2.2^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/2.2^{commit} # timeout=10
Checking out Revision ac86777a6bcb86a21e5efaad196c9e3aaccbcc80 
(refs/remotes/origin/2.2)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ac86777a6bcb86a21e5efaad196c9e3aaccbcc80
Commit message: "KAFKA-9051: Prematurely complete source offset read requests 
for stopped tasks (#7532)"
 > git rev-list --no-walk b9adf4c0a9d4b4a510a281278679d0ee68b97566 # timeout=10
ERROR: No tool found matching GRADLE_4_8_1_HOME
[kafka-2.2-jdk8-old] $ /bin/bash -xe /tmp/jenkins2361474200392359800.sh
+ rm -rf 
+ /bin/gradle
/tmp/jenkins2361474200392359800.sh: line 4: /bin/gradle: No such file or 
directory
Build step 'Execute shell' marked build as failure
[FINDBUGS] Collecting findbugs analysis files...
ERROR: No tool found matching GRADLE_4_8_1_HOME
[FINDBUGS] Searching for all files in 
 that match the pattern 
**/build/reports/findbugs/*.xml
[FINDBUGS] No files found. Configuration error?
ERROR: No tool found matching GRADLE_4_8_1_HOME
No credentials specified
ERROR: No tool found matching GRADLE_4_8_1_HOME
 Using GitBlamer to create author and commit information for all 
warnings.
 GIT_COMMIT=ac86777a6bcb86a21e5efaad196c9e3aaccbcc80, 
workspace=
[FINDBUGS] Computing warning deltas based on reference build #175
Recording test results
ERROR: No tool found matching GRADLE_4_8_1_HOME
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
ERROR: No tool found matching GRADLE_4_8_1_HOME
Not sending mail to unregistered user b...@confluent.io
Not sending mail to unregistered user wangg...@gmail.com

[jira] [Created] (KAFKA-9214) test suite generates different errors each time

[AK97 (Jira)]

AK97 created KAFKA-9214:
---

 Summary: test suite generates different errors each time
 Key: KAFKA-9214
 URL: https://issues.apache.org/jira/browse/KAFKA-9214
 Project: Kafka
  Issue Type: Bug
Affects Versions: 2.3.0
 Environment: os: rhel:7.6
architecture: ppc64le
Reporter: AK97


I have been running the apache/kafka test suite approx. 6/7 times and at each 
execution it throws up a different set of errors. Some of the errors thrown are 
as follows.

However, note that they aren't the same set seen each time . 

Would like some help on understanding the cause for the same . I am running it 
on a High end VM with good connectivity.

 

Errors:

1)

org.apache.kafka.common.security.authenticator.SaslAuthenticatorTest > 
testMultipleServerMechanisms FAILED
    java.lang.AssertionError: Metric not updated 
successful-reauthentication-total expected:<0.0> but was:<1.0> expected:<0.0> 
but was:<1.0>

 

2)

kafka.admin.ResetConsumerGroupOffsetTest > testResetOffsetsExistingTopic FAILED
    java.util.concurrent.ExecutionException: 
org.apache.kafka.common.errors.CoordinatorNotAvailableException: The 
coordinator is not available

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] 2.4.0 RC0

[Manikumar]

Hi All,

Thanks you for testing RC0. The following blocker issues were fixed after
RC0.

https://issues.apache.org/jira/browse/KAFKA-9196
https://github.com/apache/kafka/pull/7691

I am canceling RC0 VOTE and will create new RC soon.

Thanks,
Manikumar

On Thu, Nov 14, 2019 at 11:51 PM Manikumar 
wrote:

> Hello Kafka users, developers and client-developers,
>
> This is the first candidate for release of Apache Kafka 2.4.0.
> There is work in progress for couple blockers PRs. I am publishing RC0 to
> avoid further delays in testing the release.
>
> This release includes many new features, including:
> - Allow consumers to fetch from closest replica
> - Support for incremental cooperative rebalancing to the consumer
> rebalance protocol
> - MirrorMaker 2.0 (MM2), a new multi-cluster, cross-datacenter replication
> engine
> - New Java authorizer Interface
> - Support for  non-key joining in KTable
> - Administrative API for replica reassignment
> - Sticky partitioner
> - Return topic metadata and configs in CreateTopics response
> - Securing Internal connect REST endpoints
> - API to delete consumer offsets and expose it via the AdminClient.
>
> Release notes for the 2.4.0 release:
> https://home.apache.org/~manikumar/kafka-2.4.0-rc0/RELEASE_NOTES.html
>
> *** Please download, test  by  Thursday, November 20, 9am PT
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> https://kafka.apache.org/KEYS
>
> * Release artifacts to be voted upon (source and binary):
> https://home.apache.org/~manikumar/kafka-2.4.0-rc0/
>
> * Maven artifacts to be voted upon:
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>
> * Javadoc:
> https://home.apache.org/~manikumar/kafka-2.4.0-rc0/javadoc/
>
> * Tag to be voted upon (off 2.4 branch) is the 2.4.0 tag:
> https://github.com/apache/kafka/releases/tag/2.4.0-rc0
>
> * Documentation:
> https://kafka.apache.org/24/documentation.html
>
> * Protocol:
> https://kafka.apache.org/24/protocol.html
>
> Thanks,
> Manikumar
>

Re: [VOTE] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

[deng ziming]

>
> For new (uncached) topics, one problem here is that we don't know which
> partition to map a record to in the event that it has a key or custom
> partitioner, so the RecordAccumulator wouldn't know which batch/broker it
> belongs. We'd need an intermediate record queue that subsequently moved the
> records into RecordAccumulators once metadata resolution was complete. For
> known topics, we don't currently block at all in waitOnMetadata.
>

You are right, I forget this fact, and the intermediate record queue will
help, but I have some questions

if we add an intermediate record queue in KafkaProducer, when should we
move the records into RecordAccumulators?
only NetworkClient is aware of the MetadataResponse, here is the
hierarchical structure of the related classes:
KafkaProducer
Accumulator
Sender
NetworkClient
metadataUpdater.handleCompletedMetadataResponse

so
1. we should also add a metadataUpdater to KafkaProducer?
2. if the topic really does not exists? the intermediate record queue will
become too large?
3. and should we `block` when the intermediate record queue is too large?
and this will again bring the blocking problem?



On Wed, Nov 20, 2019 at 12:40 AM Brian Byrne  wrote:

> Hi Deng,
>
> Thanks for the feedback.
>
> On Mon, Nov 18, 2019 at 6:56 PM deng ziming 
> wrote:
>
> > hi, I reviewed the current code, the ProduceMetadata maintains an expiry
> > threshold for every topic, every time when we write to a topic we will
> set
> > the expiry time to -1 to indicate it should be updated, this does work to
> > reduce the size of the topic working set, but the producer will continue
> > fetching metadata for these topics in every metadata request for the full
> > expiry duration.
> >
>
> Indeed, you are correct, I terribly misread the code here. Fortunately this
> was only a minor optimization in the KIP that's no longer necessary.
>
>
> and we can improve the situation by 2 means:
> > 1. we maintain a refresh threshold for every topic which is for
> example
> > 0.8 * expiry_threshold, and when we send `MetadataRequest` to brokers we
> > just request unknownLeaderTopics + unknownPartitionTopics + topics
> > reach refresh threshold.
> >
>
> Right, this is similar to what I suggested, with a larger window on the
> "staleness" that permits for batching to an appropriate size (except if
> there's any unknown topics, you'd want to issue the request immediately).
>
>
>
> > 2. we don't invoke KafkaProducer#waitOnMetadata when we call
> > KafkaProducer#send because of we just send data to RecordAccumulator, and
> > before we send data to brokers we will invoke RecordAccumulator#ready(),
> so
> > we can only invoke waitOnMetadata to block when (number topics
> > reach refresh threshold)>(number of all known topics)*0.2.
> >
>
> For new (uncached) topics, one problem here is that we don't know which
> partition to map a record to in the event that it has a key or custom
> partitioner, so the RecordAccumulator wouldn't know which batch/broker it
> belongs. We'd need an intermediate record queue that subsequently moved the
> records into RecordAccumulators once metadata resolution was complete. For
> known topics, we don't currently block at all in waitOnMetadata.
>
> The last major point of minimizing producer startup metadata RPCs may still
> need to be improved, but this would be a large improvement on the current
> situation.
>
> Thanks,
> Brian
>
>
>
> > I think the above 2 ways are enough to solve the current problem.
> >
> > On Tue, Nov 19, 2019 at 3:20 AM Colin McCabe  wrote:
> >
> > > On Mon, Nov 18, 2019, at 10:05, Brian Byrne wrote:
> > > > On Fri, Nov 15, 2019 at 5:08 PM Colin McCabe 
> > wrote:
> > > >
> > > > > Two seconds doesn't seem like a reasonable amount of time to leave
> > for
> > > the
> > > > > metadata fetch.  Fetching halfway through the expiration period
> seems
> > > more
> > > > > reasonable.  It also doesn't require us to create a new
> configuration
> > > key,
> > > > > which is nice.
> > > > >
> > > > > Another option is to just do the metadata fetch every
> > > metadata.max.age.ms,
> > > > > but not expire the topic until we can't fetch the metadata for 2 *
> > > > > metadata.max.age.ms.
> > > > >
> > > >
> > > > I'd expect two seconds to be reasonable in the common case. Keep in
> > mind
> > > > that this doesn't affect correctness, and a control operation
> returning
> > > > cached metadata should be on the order of milliseconds.
> > > >
> > >
> > > Hi Brian,
> > >
> > > Thanks again for the KIP.
> > >
> > > I think the issue here is not the common case, but the uncommon case
> > where
> > > the metadata fetch takes longer than expected.  In that case, we don't
> > want
> > > to be in the position of having our metadata expire because we waited
> too
> > > long to renew it.
> > >
> > > This is one reason why I think that the metadata expiration time should
> > be
> > > longer than the metadata refresh time.  In fact, it might be 

Build failed in Jenkins: kafka-trunk-jdk8 #4054

[Apache Jenkins Server]

See 


Changes:

[github] Fix missing reference in kafka.py (#7715)


--
[...truncated 5.55 MB...]

org.apache.kafka.streams.test.TestRecordTest > testMultiFieldMatcher PASSED

org.apache.kafka.streams.test.TestRecordTest > testFields STARTED

org.apache.kafka.streams.test.TestRecordTest > testFields PASSED

org.apache.kafka.streams.test.TestRecordTest > testProducerRecord STARTED

org.apache.kafka.streams.test.TestRecordTest > testProducerRecord PASSED

org.apache.kafka.streams.test.TestRecordTest > testEqualsAndHashCode STARTED

org.apache.kafka.streams.test.TestRecordTest > testEqualsAndHashCode PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordsFromKeyValuePairs STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordsFromKeyValuePairs PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKeyAndDefaultTimestamp 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKeyAndDefaultTimestamp 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithDefaultTimestamp 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithDefaultTimestamp 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKey STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKey PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecordWithOtherTopicNameAndTimestampWithTimetamp 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecordWithOtherTopicNameAndTimestampWithTimetamp 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithTimestamp STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithTimestamp PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullHeaders STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullHeaders PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithDefaultTimestamp STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithDefaultTimestamp PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicName STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicName PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithNullKey STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithNullKey PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecord STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecord PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecord STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecord PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithOtherTopicName STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithOtherTopicName PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > shouldAdvanceTime 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > shouldAdvanceTime 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithKeyValuePairs STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithKeyValuePairs PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairsAndCustomTimestamps
 STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairsAndCustomTimestamps
 PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairs 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairs PASSED

Re: [DISCUSS] KIP-405: Kafka Tiered Storage

[Ying Zheng]

Please ignore my previous email
I didn't know Apache requires all the discussions to be "open"

On Tue, Nov 19, 2019, 5:40 PM Ying Zheng  wrote:

> Hi Jun,
>
> Thank you very much for your feedback!
>
> Can we schedule a meeting in your Palo Alto office in December? I think a
> face to face discussion is much more efficient than emails. Both Harsha and
> I can visit you. Satish may be able to join us remotely.
>
> On Fri, Nov 15, 2019 at 11:04 AM Jun Rao  wrote:
>
>> Hi, Satish and Harsha,
>>
>> The following is a more detailed high level feedback for the KIP. Overall,
>> the KIP seems useful. The challenge is how to design it such that it’s
>> general enough to support different ways of implementing this feature and
>> support existing features.
>>
>> 40. Local segment metadata storage: The KIP makes the assumption that the
>> metadata for the archived log segments are cached locally in every broker
>> and provides a specific implementation for the local storage in the
>> framework. We probably should discuss this more. For example, some tier
>> storage providers may not want to cache the metadata locally and just rely
>> upon a remote key/value store if such a store is already present. If a
>> local store is used, there could be different ways of implementing it
>> (e.g., based on customized local files, an embedded local store like
>> RocksDB, etc). An alternative of designing this is to just provide an
>> interface for retrieving the tier segment metadata and leave the details
>> of
>> how to get the metadata outside of the framework.
>>
>> 41. RemoteStorageManager interface and the usage of the interface in the
>> framework: I am not sure if the interface is general enough.  For example,
>> it seems that RemoteLogIndexEntry is tied to a specific way of storing the
>> metadata in remote storage. The framework uses listRemoteSegments() api in
>> a pull based approach. However, in some other implementations, a push
>> based
>> approach may be more preferred. I don’t have a concrete proposal yet. But,
>> it would be useful to give this area some more thoughts and see if we can
>> make the interface more general.
>>
>> 42. In the diagram, the RemoteLogManager is side by side with LogManager.
>> This KIP only discussed how the fetch request is handled between the two
>> layer. However, we should also consider how other requests that touch the
>> log can be handled. e.g., list offsets by timestamp, delete records, etc.
>> Also, in this model, it's not clear which component is responsible for
>> managing the log start offset. It seems that the log start offset could be
>> changed by both RemoteLogManager and LogManager.
>>
>> 43. There are quite a few existing features not covered by the KIP. It
>> would be useful to discuss each of those.
>> 43.1 I won’t say that compacted topics are rarely used and always small.
>> For example, KStreams uses compacted topics for storing the states and
>> sometimes the size of the topic could be large. While it might be ok to
>> not
>> support compacted topics initially, it would be useful to have a high
>> level
>> idea on how this might be supported down the road so that we don’t have to
>> make incompatible API changes in the future.
>> 43.2 We need to discuss how EOS is supported. In particular, how is the
>> producer state integrated with the remote storage.
>> 43.3 Now that KIP-392 (allow consumers to fetch from closest replica) is
>> implemented, we need to discuss how reading from a follower replica is
>> supported with tier storage.
>> 43.4 We need to discuss how JBOD is supported with tier storage.
>>
>> Thanks,
>>
>> Jun
>>
>> On Fri, Nov 8, 2019 at 12:06 AM Tom Bentley  wrote:
>>
>> > Thanks for those insights Ying.
>> >
>> > On Thu, Nov 7, 2019 at 9:26 PM Ying Zheng 
>> wrote:
>> >
>> > > >
>> > > >
>> > > >
>> > > > Thanks, I missed that point. However, there's still a point at which
>> > the
>> > > > consumer fetches start getting served from remote storage (even if
>> that
>> > > > point isn't as soon as the local log retention time/size). This
>> > > represents
>> > > > a kind of performance cliff edge and what I'm really interested in
>> is
>> > how
>> > > > easy it is for a consumer which falls off that cliff to catch up
>> and so
>> > > its
>> > > > fetches again come from local storage. Obviously this can depend on
>> all
>> > > > sorts of factors (like production rate, consumption rate), so it's
>> not
>> > > > guaranteed (just like it's not guaranteed for Kafka today), but this
>> > > would
>> > > > represent a new failure mode.
>> > > >
>> > >
>> > >  As I have explained in the last mail, it's a very rare case that a
>> > > consumer
>> > > need to read remote data. With our experience at Uber, this only
>> happens
>> > > when the consumer service had an outage for several hours.
>> > >
>> > > There is not a "performance cliff" as you assume. The remote storage
>> is
>> > > even faster than local disks in terms of bandwidth. Reading from
>> remote
>> 

Re: [DISCUSS] KIP-405: Kafka Tiered Storage

[Ying Zheng]

Hi Jun,

Thank you very much for your feedback!

Can we schedule a meeting in your Palo Alto office in December? I think a
face to face discussion is much more efficient than emails. Both Harsha and
I can visit you. Satish may be able to join us remotely.

On Fri, Nov 15, 2019 at 11:04 AM Jun Rao  wrote:

> Hi, Satish and Harsha,
>
> The following is a more detailed high level feedback for the KIP. Overall,
> the KIP seems useful. The challenge is how to design it such that it’s
> general enough to support different ways of implementing this feature and
> support existing features.
>
> 40. Local segment metadata storage: The KIP makes the assumption that the
> metadata for the archived log segments are cached locally in every broker
> and provides a specific implementation for the local storage in the
> framework. We probably should discuss this more. For example, some tier
> storage providers may not want to cache the metadata locally and just rely
> upon a remote key/value store if such a store is already present. If a
> local store is used, there could be different ways of implementing it
> (e.g., based on customized local files, an embedded local store like
> RocksDB, etc). An alternative of designing this is to just provide an
> interface for retrieving the tier segment metadata and leave the details of
> how to get the metadata outside of the framework.
>
> 41. RemoteStorageManager interface and the usage of the interface in the
> framework: I am not sure if the interface is general enough.  For example,
> it seems that RemoteLogIndexEntry is tied to a specific way of storing the
> metadata in remote storage. The framework uses listRemoteSegments() api in
> a pull based approach. However, in some other implementations, a push based
> approach may be more preferred. I don’t have a concrete proposal yet. But,
> it would be useful to give this area some more thoughts and see if we can
> make the interface more general.
>
> 42. In the diagram, the RemoteLogManager is side by side with LogManager.
> This KIP only discussed how the fetch request is handled between the two
> layer. However, we should also consider how other requests that touch the
> log can be handled. e.g., list offsets by timestamp, delete records, etc.
> Also, in this model, it's not clear which component is responsible for
> managing the log start offset. It seems that the log start offset could be
> changed by both RemoteLogManager and LogManager.
>
> 43. There are quite a few existing features not covered by the KIP. It
> would be useful to discuss each of those.
> 43.1 I won’t say that compacted topics are rarely used and always small.
> For example, KStreams uses compacted topics for storing the states and
> sometimes the size of the topic could be large. While it might be ok to not
> support compacted topics initially, it would be useful to have a high level
> idea on how this might be supported down the road so that we don’t have to
> make incompatible API changes in the future.
> 43.2 We need to discuss how EOS is supported. In particular, how is the
> producer state integrated with the remote storage.
> 43.3 Now that KIP-392 (allow consumers to fetch from closest replica) is
> implemented, we need to discuss how reading from a follower replica is
> supported with tier storage.
> 43.4 We need to discuss how JBOD is supported with tier storage.
>
> Thanks,
>
> Jun
>
> On Fri, Nov 8, 2019 at 12:06 AM Tom Bentley  wrote:
>
> > Thanks for those insights Ying.
> >
> > On Thu, Nov 7, 2019 at 9:26 PM Ying Zheng 
> wrote:
> >
> > > >
> > > >
> > > >
> > > > Thanks, I missed that point. However, there's still a point at which
> > the
> > > > consumer fetches start getting served from remote storage (even if
> that
> > > > point isn't as soon as the local log retention time/size). This
> > > represents
> > > > a kind of performance cliff edge and what I'm really interested in is
> > how
> > > > easy it is for a consumer which falls off that cliff to catch up and
> so
> > > its
> > > > fetches again come from local storage. Obviously this can depend on
> all
> > > > sorts of factors (like production rate, consumption rate), so it's
> not
> > > > guaranteed (just like it's not guaranteed for Kafka today), but this
> > > would
> > > > represent a new failure mode.
> > > >
> > >
> > >  As I have explained in the last mail, it's a very rare case that a
> > > consumer
> > > need to read remote data. With our experience at Uber, this only
> happens
> > > when the consumer service had an outage for several hours.
> > >
> > > There is not a "performance cliff" as you assume. The remote storage is
> > > even faster than local disks in terms of bandwidth. Reading from remote
> > > storage is going to have higher latency than local disk. But since the
> > > consumer
> > > is catching up several hours data, it's not sensitive to the sub-second
> > > level
> > > latency, and each remote read request will read a large amount of data
> to
> > > make the 

Re: [DISCUSS] KIP-405: Kafka Tiered Storage

[Ying Zheng]

On Fri, Nov 15, 2019 at 11:04 AM Jun Rao  wrote:

> Hi, Satish and Harsha,
>
> The following is a more detailed high level feedback for the KIP. Overall,
> the KIP seems useful. The challenge is how to design it such that it’s
> general enough to support different ways of implementing this feature and
> support existing features.
>
> 40. Local segment metadata storage: The KIP makes the assumption that the
> metadata for the archived log segments are cached locally in every broker
> and provides a specific implementation for the local storage in the
> framework. We probably should discuss this more. For example, some tier
> storage providers may not want to cache the metadata locally and just rely
> upon a remote key/value store if such a store is already present. If a
> local store is used, there could be different ways of implementing it
> (e.g., based on customized local files, an embedded local store like
> RocksDB, etc). An alternative of designing this is to just provide an
> interface for retrieving the tier segment metadata and leave the details of
> how to get the metadata outside of the framework.
>

[Ying]
Early this year, when we just started design tiered storage, we did plan to
make RemoteLogManager
a Kafka plugin. So that, there can be totally different implementations of
tiered storage.

However, one feedback we received from the community is that
developing RemoteLogManager
implementations are too hard for most potential users. People actually
prefer to one standard
implementation that can satisfy most of the requirements.

We accepted that feedback, and decided to trade some of the flexibility for
simplicity in the 1st version.
It's still possible to allow users provide different implementations in the
future.

We had discussions with different companies (e.g. Slack, AirBnb) that are
interested in tiered storage.
Our conclusion is that the current design (a standard RemoteLogManager that
caches remote metadata
locally + HDFS and S3 RemoteStorageMangers) is good enough for all of the
companies we have talked
with.

We don't have much knowledge about the use-cases out of Internet industry.
Do any consumers of
Confluent need to manage the metadata in different ways?





> 43. There are quite a few existing features not covered by the KIP. It
> would be useful to discuss each of those.
> 43.1 I won’t say that compacted topics are rarely used and always small.
> For example, KStreams uses compacted topics for storing the states and
> sometimes the size of the topic could be large. While it might be ok to not
> support compacted topics initially, it would be useful to have a high level
> idea on how this might be supported down the road so that we don’t have to
> make incompatible API changes in the future.
> 43.2 We need to discuss how EOS is supported. In particular, how is the
> producer state integrated with the remote storage.
> 43.3 Now that KIP-392 (allow consumers to fetch from closest replica) is
> implemented, we need to discuss how reading from a follower replica is
> supported with tier storage.
> 43.4 We need to discuss how JBOD is supported with tier storage.
>
> [Ying]
The support of compacted topics and EOS are definitely possible. We will
discuss the possible design in the KIP.

But for the 1st version, we prefer to focus on a relatively small scope, and
develop a simple and just enough solution for most users. Most features
will be gradually added in the future releases.

For compacted topic, we can save a new version of remote segment files
after each compact. The old remote version will be deleted after the new
version is available on remote storage.

For EOS, the snapshots can also be shipped to remote storage.

KIP-392 will be supported in the 1st version of tiered storage. We will add
the design details in the KIP.

JBOD of in remote storage is provided by the remote storage system
(e.g. HDFS, S3). This should be totally transparent for Kafka.

Tiered storage will make Kafka local storage much smaller, and make
JBOD of local storage less needed. We should be able to support JBOD
in local storage in the future. This shouldn't require any changes in RSM,
because only Kafka and RemoteLogManager talk with local storage.
So, there shouldn't be any compatibility issue when we support local
storage JBOD in the next version.



> Thanks,
>
> Jun
>
>
>

Build failed in Jenkins: kafka-trunk-jdk11 #969

[Apache Jenkins Server]

See 


Changes:

[github] Fix missing reference in kafka.py (#7715)

[bill] HOTFIX: safely clear all active state in onPartitionsLost (#7691)


--
[...truncated 2.74 MB...]

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestampWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestampWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueIsEqualWithNullForCompareValueWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueIsEqualWithNullForCompareValueWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfTimestampIsDifferentForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfTimestampIsDifferentForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualWithNullForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualWithNullForCompareKeyValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestampWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestampWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordWithExpectedRecordForCompareValueTimestamp 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordWithExpectedRecordForCompareValueTimestamp 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullExpectedRecordForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullExpectedRecordForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareKeyValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareKeyValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualForCompareKeyValueTimestamp STARTED

[jira] [Created] (KAFKA-9213) BufferOverflowException on rolling new segment after upgrading Kafka from 1.1.0 to 2.3.1

[Daniyar (Jira)]

Daniyar created KAFKA-9213:
--

 Summary: BufferOverflowException on rolling new segment after 
upgrading Kafka from 1.1.0 to 2.3.1
 Key: KAFKA-9213
 URL: https://issues.apache.org/jira/browse/KAFKA-9213
 Project: Kafka
  Issue Type: Bug
  Components: log
Affects Versions: 2.3.1
 Environment: Ubuntu 16.04, AWS instance d2.8xlarge.

JAVA Options:

-Xms16G 
-Xmx16G 
-XX:G1HeapRegionSize=16M 
-XX:MetaspaceSize=96m 
-XX:MinMetaspaceFreeRatio=50 
Reporter: Daniyar


We updated our Kafka cluster from 1.1.0 version to 2.3.1. We followed up to 
step 2 of the [update 
instruction|[https://kafka.apache.org/documentation/#upgrade]].

Message format and inter-broker protocol versions were left the same:

inter.broker.protocol.version=1.1

log.message.format.version=1.1

 

After upgrading, we started to get some occasional exceptions:
{code:java}
2019/11/19 05:30:53 INFO [ProducerStateManager
partition=matchmaker_retry_clicks_15m-2] Writing producer snapshot at
offset 788532 (kafka.log.ProducerStateManager)
2019/11/19 05:30:53 INFO [Log partition=matchmaker_retry_clicks_15m-2,
dir=/mnt/kafka] Rolled new log segment at offset 788532 in 1 ms.
(kafka.log.Log)
2019/11/19 05:31:01 ERROR [ReplicaManager broker=0] Error processing append
operation on partition matchmaker_retry_clicks_15m-2
(kafka.server.ReplicaManager)
2019/11/19 05:31:01 java.nio.BufferOverflowException
2019/11/19 05:31:01 at java.nio.Buffer.nextPutIndex(Buffer.java:527)
2019/11/19 05:31:01 at
java.nio.DirectByteBuffer.putLong(DirectByteBuffer.java:797)
2019/11/19 05:31:01 at
kafka.log.TimeIndex.$anonfun$maybeAppend$1(TimeIndex.scala:134)
2019/11/19 05:31:01 at
scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
2019/11/19 05:31:01 at
kafka.utils.CoreUtils$.inLock(CoreUtils.scala:253)
2019/11/19 05:31:01 at
kafka.log.TimeIndex.maybeAppend(TimeIndex.scala:114)
2019/11/19 05:31:01 at
kafka.log.LogSegment.onBecomeInactiveSegment(LogSegment.scala:520)
2019/11/19 05:31:01 at kafka.log.Log.$anonfun$roll$8(Log.scala:1690)
2019/11/19 05:31:01 at
kafka.log.Log.$anonfun$roll$8$adapted(Log.scala:1690)
2019/11/19 05:31:01 at scala.Option.foreach(Option.scala:407)
2019/11/19 05:31:01 at kafka.log.Log.$anonfun$roll$2(Log.scala:1690)
2019/11/19 05:31:01 at
kafka.log.Log.maybeHandleIOException(Log.scala:2085)
2019/11/19 05:31:01 at kafka.log.Log.roll(Log.scala:1654)
2019/11/19 05:31:01 at kafka.log.Log.maybeRoll(Log.scala:1639)
2019/11/19 05:31:01 at kafka.log.Log.$anonfun$append$2(Log.scala:966)
2019/11/19 05:31:01 at
kafka.log.Log.maybeHandleIOException(Log.scala:2085)
2019/11/19 05:31:01 at kafka.log.Log.append(Log.scala:850)
2019/11/19 05:31:01 at kafka.log.Log.appendAsLeader(Log.scala:819)
2019/11/19 05:31:01 at
kafka.cluster.Partition.$anonfun$appendRecordsToLeader$1(Partition.scala:772)
2019/11/19 05:31:01 at
kafka.utils.CoreUtils$.inLock(CoreUtils.scala:253)
2019/11/19 05:31:01 at
kafka.utils.CoreUtils$.inReadLock(CoreUtils.scala:259)
2019/11/19 05:31:01 at
kafka.cluster.Partition.appendRecordsToLeader(Partition.scala:759)
2019/11/19 05:31:01 at
kafka.server.ReplicaManager.$anonfun$appendToLocalLog$2(ReplicaManager.scala:763)
2019/11/19 05:31:01 at
scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:238)
2019/11/19 05:31:01 at
scala.collection.mutable.HashMap.$anonfun$foreach$1(HashMap.scala:149)
2019/11/19 05:31:01 at
scala.collection.mutable.HashTable.foreachEntry(HashTable.scala:237)
2019/11/19 05:31:01 at
scala.collection.mutable.HashTable.foreachEntry$(HashTable.scala:230)
2019/11/19 05:31:01 at
scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:44)
2019/11/19 05:31:01 at
scala.collection.mutable.HashMap.foreach(HashMap.scala:149)
2019/11/19 05:31:01 at
scala.collection.TraversableLike.map(TraversableLike.scala:238)
2019/11/19 05:31:01 at
scala.collection.TraversableLike.map$(TraversableLike.scala:231)
2019/11/19 05:31:01 at
scala.collection.AbstractTraversable.map(Traversable.scala:108)
2019/11/19 05:31:01 at
kafka.server.ReplicaManager.appendToLocalLog(ReplicaManager.scala:751)
2019/11/19 05:31:01 at
kafka.server.ReplicaManager.appendRecords(ReplicaManager.scala:492)
2019/11/19 05:31:01 at
kafka.server.KafkaApis.handleProduceRequest(KafkaApis.scala:544)
2019/11/19 05:31:01 at
kafka.server.KafkaApis.handle(KafkaApis.scala:113)
2019/11/19 05:31:01 at
kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:69)
2019/11/19 05:31:01 at java.lang.Thread.run(Thread.java:748)

{code}
The error persists until broker gets restarted (or leadership gets moved to 
another broker).

 

Brokers config:
{code:java}
advertised.host.name={{ hostname }}
port=9092

# Default number of partitions if a value isn't set when the topic is created.

[jira] [Created] (KAFKA-9212) Keep receiving FENCED_LEADER_EPOCH while sending ListOffsetRequest

[Yannick (Jira)]

Yannick created KAFKA-9212:
--

 Summary: Keep receiving FENCED_LEADER_EPOCH while sending 
ListOffsetRequest
 Key: KAFKA-9212
 URL: https://issues.apache.org/jira/browse/KAFKA-9212
 Project: Kafka
  Issue Type: Bug
  Components: consumer, offset manager
Affects Versions: 2.3.0
 Environment: Linux
Reporter: Yannick


When running Kafka connect s3 sink connector ( confluent 5.3.0), after one 
broker got restarted, the connect worker crashed with the following error : 

[2019-11-19 16:20:30,097] ERROR [Worker clientId=connect-1, groupId=connect-ls] 
Uncaught exception in herder work thread, exiting: 
(org.apache.kafka.connect.runtime.distributed.DistributedHerder:253)
org.apache.kafka.common.errors.TimeoutException: Failed to get offsets by times 
in 30003ms

 

After investigation, it seems it's because it got fenced when sending 
ListOffsetRequest in loop and then got timed out , as follows :

[2019-11-19 16:20:30,020] DEBUG [Consumer clientId=consumer-3, 
groupId=connect-ls] Sending ListOffsetRequest (type=ListOffsetRequest, 
replicaId=-1, partitionTimestamps=\{connect_ls_config-0={timestamp: -1, 
maxNumOffsets: 1, currentLeaderEpoch: Optional[1]}}, 
isolationLevel=READ_UNCOMMITTED) to broker kafka6.fra2.internal:9092 (id: 4 
rack: null) (org.apache.kafka.clients.consumer.internals.Fetcher:905)

[2019-11-19 16:20:30,044] DEBUG [Consumer clientId=consumer-3, 
groupId=connect-ls] Attempt to fetch offsets for partition connect_ls_config-0 
failed due to FENCED_LEADER_EPOCH, retrying. 
(org.apache.kafka.clients.consumer.internals.Fetcher:985)

 

This multiple times until timeout.

 

According to the debugs, the consumer always get a leaderEpoch of 1 for this 
topic when starting up :

 
[2019-11-19 13:27:30,802] DEBUG [Consumer clientId=consumer-3, 
groupId=connect-ls] Updating last seen epoch from null to 1 for partition 
connect_ls_config-0 (org.apache.kafka.clients.Metadata:178)
 
 
But according to our brokers log, the leaderEpoch should be 2, as follows :
 
[2019-11-18 14:19:28,988] INFO [Partition connect_ls_config-0 broker=4] 
connect_ls_config-0 starts at Leader Epoch 2 from offset 22. Previous Leader 
Epoch was: 1 (kafka.cluster.Partition)
 
 
This make impossible to restart the worker as it will always get fenced and 
then finally timeout.
 
It is also impossible to consumer with a 2.3 kafka-console-consumer as follows :
 
kafka-console-consumer --bootstrap-server BOOTSTRAPSERVER:9092 --topic 
connect_ls_config --from-beginning 
 
the above will just hang forever ( which is not expected cause there is data)
 
 
Interesting fact, if we do subscribe the same way with kafkacat (1.5.0) we can 
consume without problem ( must be the way kafkacat is consuming which is 
different somehow):
 
kafkacat -b BOOTSTRAPSERVER:9092 -t connect_ls_config -o beginning
 
 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Build failed in Jenkins: kafka-trunk-jdk11 #968

[Apache Jenkins Server]

See 


Changes:

[bbejeck] KAFKA-9086: Refactor processor-node-level metrics (#7615)


--
[...truncated 2.74 MB...]

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldNotCreateStateDirectoryForStatelessTopology[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldNotCreateStateDirectoryForStatelessTopology[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldReturnAllStoresNames[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldReturnAllStoresNames[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldProcessConsumerRecordList[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldProcessConsumerRecordList[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldUseSinkSpecificSerializers[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldUseSinkSpecificSerializers[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldFlushStoreForFirstInput[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldFlushStoreForFirstInput[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldProcessFromSourceThatMatchPattern[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldProcessFromSourceThatMatchPattern[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldUpdateStoreForNewKey[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldUpdateStoreForNewKey[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldSendRecordViaCorrectSourceTopicDeprecated[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldSendRecordViaCorrectSourceTopicDeprecated[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldPunctuateOnWallClockTime[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldPunctuateOnWallClockTime[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > shouldSetRecordMetadata[Eos 
enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > shouldSetRecordMetadata[Eos 
enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldNotUpdateStoreForLargerValue[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldNotUpdateStoreForLargerValue[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldReturnCorrectInMemoryStoreTypeOnly[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldReturnCorrectInMemoryStoreTypeOnly[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > shouldThrowForMissingTime[Eos 
enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > shouldThrowForMissingTime[Eos 
enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldPunctuateOnWallClockTimeDeprecated[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldPunctuateOnWallClockTimeDeprecated[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldProcessRecordForTopic[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldProcessRecordForTopic[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldForwardRecordsFromSubtopologyToSubtopology[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldForwardRecordsFromSubtopologyToSubtopology[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldNotUpdateStoreForSmallerValue[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldNotUpdateStoreForSmallerValue[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldCreateStateDirectoryForStatefulTopology[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldCreateStateDirectoryForStatefulTopology[Eos enabled = false] PASSED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldPunctuateIfWallClockTimeAdvances[Eos enabled = false] STARTED

org.apache.kafka.streams.TopologyTestDriverTest > 
shouldPunctuateIfWallClockTimeAdvances[Eos enabled = false] PASSED

org.apache.kafka.streams.internals.KeyValueStoreFacadeTest > shouldReturnIsOpen 
STARTED

org.apache.kafka.streams.internals.KeyValueStoreFacadeTest > shouldReturnIsOpen 
PASSED

org.apache.kafka.streams.internals.KeyValueStoreFacadeTest > 
shouldDeleteAndReturnPlainValue STARTED

Build failed in Jenkins: kafka-trunk-jdk8 #4053

[Apache Jenkins Server]

See 


Changes:

[bbejeck] KAFKA-9086: Refactor processor-node-level metrics (#7615)


--
[...truncated 2.74 MB...]

org.apache.kafka.streams.test.TestRecordTest > testMultiFieldMatcher PASSED

org.apache.kafka.streams.test.TestRecordTest > testFields STARTED

org.apache.kafka.streams.test.TestRecordTest > testFields PASSED

org.apache.kafka.streams.test.TestRecordTest > testProducerRecord STARTED

org.apache.kafka.streams.test.TestRecordTest > testProducerRecord PASSED

org.apache.kafka.streams.test.TestRecordTest > testEqualsAndHashCode STARTED

org.apache.kafka.streams.test.TestRecordTest > testEqualsAndHashCode PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordsFromKeyValuePairs STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordsFromKeyValuePairs PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKeyAndDefaultTimestamp 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKeyAndDefaultTimestamp 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithDefaultTimestamp 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithDefaultTimestamp 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKey STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithNullKey PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecordWithOtherTopicNameAndTimestampWithTimetamp 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecordWithOtherTopicNameAndTimestampWithTimetamp 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithTimestamp STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithTimestamp PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullHeaders STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullHeaders PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithDefaultTimestamp STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithDefaultTimestamp PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicName STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicName PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithNullKey STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithNullKey PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecord STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecord PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecord STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateNullKeyConsumerRecord PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithOtherTopicName STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldCreateConsumerRecordWithOtherTopicName PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > shouldAdvanceTime 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > shouldAdvanceTime 
PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithKeyValuePairs STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldNotAllowToCreateTopicWithNullTopicNameWithKeyValuePairs PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairsAndCustomTimestamps
 STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairsAndCustomTimestamps
 PASSED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairs 
STARTED

org.apache.kafka.streams.test.ConsumerRecordFactoryTest > 
shouldRequireCustomTopicNameIfNotDefaultFactoryTopicNameWithKeyValuePairs PASSED

[jira] [Resolved] (KAFKA-9086) Refactor Processor Node Streams Metrics

[Bill Bejeck (Jira)]

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

Bill Bejeck resolved KAFKA-9086.

Resolution: Fixed

> Refactor Processor Node Streams Metrics
> ---
>
> Key: KAFKA-9086
> URL: https://issues.apache.org/jira/browse/KAFKA-9086
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Reporter: Bruno Cadonna
>Assignee: Bruno Cadonna
>Priority: Major
> Fix For: 2.5.0
>
>
> Refactor processor node metrics as described in KIP-444. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [kafka-clients] [VOTE] 2.4.0 RC0

[Eric Lalonde]

Hi all,

Also seeing repeated failures of kafka.api.SaslPlainPlaintextConsumerTest > 
testCoordinatorFailover:

kafka.api.SaslPlainPlaintextConsumerTest > testCoordinatorFailover FAILED
java.lang.AssertionError: expected: but 
was:


Given the nature of the error, it may be a timing issue in the test itself, but 
it is repeatable, so I thought I’d raise it. 

To reproduce:

$ ./gradlew integrationTest



> On Nov 18, 2019, at 11:02 AM, Eric Lalonde  wrote:
> 
> This test has been failing when executed from the command line. I have not 
> run this test in an IDE. 
> 
>> On Nov 18, 2019, at 6:16 AM, Bruno Cadonna > > wrote:
>> 
>> Hi,
>> 
>> ClientMetricsTest.shouldAddCommitIdMetric should only fail if executed
>> from an IDE. The test fails because the test expects a file on the
>> class path which is not there when the test is executed from the IDE,
>> but is there when the test is executed from gradle. I will try to fix
>> the test so that it can also be executed from the IDE.
>> 
>> Best,
>> Bruno
>> 
>> On Mon, Nov 18, 2019 at 6:51 AM Vahid Hashemian
>> mailto:vahid.hashem...@gmail.com>> wrote:
>>> 
>>> Thanks Manikumar for managing this release. Looking forward to it.
>>> 
>>> I built binary from the source and was able to successfully run the 
>>> quickstarts.
>>> 
>>> However, this streams unit test also fails for me constantly:
>>> 
>>> ClientMetricsTest. shouldAddCommitIdMetric
>>> 
>>> java.lang.AssertionError:
>>>  Unexpected method call 
>>> StreamsMetricsImpl.addClientLevelImmutableMetric("commit-id", "The version 
>>> control commit ID of the Kafka Streams client", INFO, "unknown"):
>>>StreamsMetricsImpl.addClientLevelImmutableMetric("commit-id", "The 
>>> version control commit ID of the Kafka Streams client", INFO, 
>>> and(not("unknown"), notNull())): expected: 1, actual: 0
>>> at 
>>> org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:44)
>>> at 
>>> org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:101)
>>> at 
>>> org.easymock.internal.ClassProxyFactory$MockMethodInterceptor.intercept(ClassProxyFactory.java:97)
>>>...
>>> 
>>> Thanks,
>>> --Vahid
>>> 
>>> On Thu, Nov 14, 2019 at 10:21 AM Manikumar >> > wrote:
 
 Hello Kafka users, developers and client-developers,
 
 This is the first candidate for release of Apache Kafka 2.4.0.
 There is work in progress for couple blockers PRs. I am publishing RC0 to 
 avoid further delays in testing the release.
 
 This release includes many new features, including:
 - Allow consumers to fetch from closest replica
 - Support for incremental cooperative rebalancing to the consumer 
 rebalance protocol
 - MirrorMaker 2.0 (MM2), a new multi-cluster, cross-datacenter replication 
 engine
 - New Java authorizer Interface
 - Support for  non-key joining in KTable
 - Administrative API for replica reassignment
 - Sticky partitioner
 - Return topic metadata and configs in CreateTopics response
 - Securing Internal connect REST endpoints
 - API to delete consumer offsets and expose it via the AdminClient.
 
 Release notes for the 2.4.0 release:
 https://home.apache.org/~manikumar/kafka-2.4.0-rc0/RELEASE_NOTES.html 
 
 
 *** Please download, test  by  Thursday, November 20, 9am PT
 
 Kafka's KEYS file containing PGP keys we use to sign the release:
 https://kafka.apache.org/KEYS
 
 * Release artifacts to be voted upon (source and binary):
 https://home.apache.org/~manikumar/kafka-2.4.0-rc0/
 
 * Maven artifacts to be voted upon:
 https://repository.apache.org/content/groups/staging/org/apache/kafka/
 
 * Javadoc:
 https://home.apache.org/~manikumar/kafka-2.4.0-rc0/javadoc/
 
 * Tag to be voted upon (off 2.4 branch) is the 2.4.0 tag:
 https://github.com/apache/kafka/releases/tag/2.4.0-rc0
 
 * Documentation:
 https://kafka.apache.org/24/documentation.html
 
 * Protocol:
 https://kafka.apache.org/24/protocol.html
 
 Thanks,
 Manikumar
 
 --
 You received this message because you are subscribed to the Google Groups 
 "kafka-clients" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to kafka-clients+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/kafka-clients/CAMVt_Aw945uqcpisFjZHAR5m8Sidw6hW4ia%2B7%3DjxEfadmBPzcw%40mail.gmail.com.
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Thanks!
>>> --Vahid
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "kafka-clients" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to kafka-clients+unsubscr...@googlegroups.com 
>>> 

Re: [VOTE] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

[Brian Byrne]

Hi Deng,

Thanks for the feedback.

On Mon, Nov 18, 2019 at 6:56 PM deng ziming 
wrote:

> hi, I reviewed the current code, the ProduceMetadata maintains an expiry
> threshold for every topic, every time when we write to a topic we will set
> the expiry time to -1 to indicate it should be updated, this does work to
> reduce the size of the topic working set, but the producer will continue
> fetching metadata for these topics in every metadata request for the full
> expiry duration.
>

Indeed, you are correct, I terribly misread the code here. Fortunately this
was only a minor optimization in the KIP that's no longer necessary.


and we can improve the situation by 2 means:
> 1. we maintain a refresh threshold for every topic which is for example
> 0.8 * expiry_threshold, and when we send `MetadataRequest` to brokers we
> just request unknownLeaderTopics + unknownPartitionTopics + topics
> reach refresh threshold.
>

Right, this is similar to what I suggested, with a larger window on the
"staleness" that permits for batching to an appropriate size (except if
there's any unknown topics, you'd want to issue the request immediately).



> 2. we don't invoke KafkaProducer#waitOnMetadata when we call
> KafkaProducer#send because of we just send data to RecordAccumulator, and
> before we send data to brokers we will invoke RecordAccumulator#ready(), so
> we can only invoke waitOnMetadata to block when (number topics
> reach refresh threshold)>(number of all known topics)*0.2.
>

For new (uncached) topics, one problem here is that we don't know which
partition to map a record to in the event that it has a key or custom
partitioner, so the RecordAccumulator wouldn't know which batch/broker it
belongs. We'd need an intermediate record queue that subsequently moved the
records into RecordAccumulators once metadata resolution was complete. For
known topics, we don't currently block at all in waitOnMetadata.

The last major point of minimizing producer startup metadata RPCs may still
need to be improved, but this would be a large improvement on the current
situation.

Thanks,
Brian



> I think the above 2 ways are enough to solve the current problem.
>
> On Tue, Nov 19, 2019 at 3:20 AM Colin McCabe  wrote:
>
> > On Mon, Nov 18, 2019, at 10:05, Brian Byrne wrote:
> > > On Fri, Nov 15, 2019 at 5:08 PM Colin McCabe 
> wrote:
> > >
> > > > Two seconds doesn't seem like a reasonable amount of time to leave
> for
> > the
> > > > metadata fetch.  Fetching halfway through the expiration period seems
> > more
> > > > reasonable.  It also doesn't require us to create a new configuration
> > key,
> > > > which is nice.
> > > >
> > > > Another option is to just do the metadata fetch every
> > metadata.max.age.ms,
> > > > but not expire the topic until we can't fetch the metadata for 2 *
> > > > metadata.max.age.ms.
> > > >
> > >
> > > I'd expect two seconds to be reasonable in the common case. Keep in
> mind
> > > that this doesn't affect correctness, and a control operation returning
> > > cached metadata should be on the order of milliseconds.
> > >
> >
> > Hi Brian,
> >
> > Thanks again for the KIP.
> >
> > I think the issue here is not the common case, but the uncommon case
> where
> > the metadata fetch takes longer than expected.  In that case, we don't
> want
> > to be in the position of having our metadata expire because we waited too
> > long to renew it.
> >
> > This is one reason why I think that the metadata expiration time should
> be
> > longer than the metadata refresh time.  In fact, it might be worth having
> > two separate configuration keys for these two values.  I could imagine a
> > user who is having trouble with metadata expiration wanting to increase
> the
> > metadata expiration time, but without increasing the metadata refresh
> > period.  In a sense, the metadata expiration time is like the ZK session
> > expiration time.  You might want to turn it up if the cluster is
> > experiencing load spikes.
> >
> > >
> > > But to the general
> > > point, defining the algorithm would mean enforcing it to fair accuracy,
> > > whereas if the suggestion is that it'll be performed at a reasonable
> > time,
> > > it allows for batching and other optimizations. Perhaps I shouldn't be
> > > regarding what's defined in a KIP to be contractual in these cases, but
> > you
> > > could consider a first implementation to collect topics whose metadata
> > has
> > > exceeded (metadata.max.age.ms / 2), and sending the batch once a
> > > constituent topic's metadata is near the expiry, or a sufficient number
> > of
> > > topics have been collected (10? 100? 1000?).
> > >
> >
> > I'm concerned that if we change the metadata caching strategy without
> > discussing it first, it may improve certain workloads but make others
> > worse.  We need to be concrete about what the proposed strategy is so
> that
> > we can really evaluate it.
> >
> > >
> > >
> > > > We should be specific about what happens if the first few metadata
> 

Build failed in Jenkins: kafka-2.4-jdk8 #79

[Apache Jenkins Server]

See 


Changes:

[matthias] HOTFIX: Fix unit tests that failed when executed from IDE (#7707)


--
[...truncated 8.15 MB...]
org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestampWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestampWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueIsEqualWithNullForCompareValueWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueIsEqualWithNullForCompareValueWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfTimestampIsDifferentForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfTimestampIsDifferentForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualWithNullForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualWithNullForCompareKeyValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestampWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestampWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordWithExpectedRecordForCompareValueTimestamp 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordWithExpectedRecordForCompareValueTimestamp 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullExpectedRecordForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullExpectedRecordForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareKeyValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareKeyValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualForCompareKeyValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualForCompareKeyValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueTimestampWithProducerRecord
 PASSED

Re: Preliminary blog post about the Apache Kafka 2.4.0 release

[Manikumar]

Hi Sean,

Thanks for the summary. Will include in the blogpost.

On Mon, Nov 18, 2019 at 11:04 PM Sean Glover 
wrote:

> Here's a summary that can go under the section "What’s new in Kafka broker,
> producer, and consumer" as an "improvement".  Feel free to rephrase as you
> see fit.
>
> When a partition is paused by the user in the consumer the partition is
> > considered "unfetchable".  When the consumer has already fetched data
> for a
> > partition, and then the partition is paused, then in the next consumer
> poll
> > all data from "unfetchable" partitions will be discarded.  In use cases
> > where pausing and resuming partitions is common during regular operation
> of
> > the consumer this can result in discarding pre-fetched data when it's not
> > necessary.  Once the partition is resumed then new fetch requests will be
> > generated and sent to the broker to get the same partition data again.
> > Depending on the frequency of pausing and resuming of partitions this can
> > impact a number of different aspects of consumer polling including:
> > broker/consumer throughput, number of consumer fetch requests, and
> > NIO-related GC concerns for regularly dereferenced byte buffers of
> > partition data.  This issue is now resolved by retaining completed fetch
> > data for partitions that are paused so that it may be returned in a
> future
> > consumer poll once the partition is resumed by the user.
> >
>
>
> See [KAFKA-7548](https://issues.apache.org/jira/browse/KAFKA-7548) for
> more
> > details.
>
>
> Regards,
> Sean
>
> On Mon, Nov 18, 2019 at 11:45 AM Ismael Juma  wrote:
>
> > That makes sense to me.
> >
> > Ismael
> >
> > On Mon, Nov 18, 2019 at 8:40 AM Sean Glover 
> > wrote:
> >
> > > Hi Manikumar,
> > >
> > > I'm putting together an akka.io blog post regarding [KAFKA-7548] -
> > > KafkaConsumer should not throw away already fetched data for paused
> > > partitions.  Since it doesn't change any user-facing APIs it has no
> KIP,
> > > but it has a significant impact on consumer use cases that frequently
> > pause
> > > and resume partitions, such as in Alpakka Kafka.  I can provide a small
> > > summary for you to include in your blog post if you think it's
> > appropriate.
> > >
> > > Regards,
> > > Sean
> > >
> > > On Mon, Nov 18, 2019 at 11:25 AM Manikumar 
> > > wrote:
> > >
> > > > Thanks Chris. will update the blog content.
> > > >
> > > > On Fri, Nov 15, 2019 at 12:34 AM Chris Egerton 
> > > > wrote:
> > > >
> > > > > Hi Manikumar,
> > > > >
> > > > > It looks like the header for KIP-440 is accurate ("KIP-440: Extend
> > > > Connect
> > > > > Converter to support headers") but the content appears to
> correspond
> > to
> > > > > KIP-481 ("SerDe Improvements for Connect Decimal type in JSON")
> > > instead.
> > > > > Could we double-check and make sure that the summary for KIP-440
> > > matches
> > > > > what was contributed for it (and it nothing was, alter the summary
> to
> > > > more
> > > > > closely reflect what KIP-440 accomplished)?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Chris
> > > > >
> > > > > On Thu, Nov 14, 2019 at 10:41 AM Manikumar <
> > manikumar.re...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I've prepared a preliminary blog post about the upcoming Apache
> > Kafka
> > > > > 2.4.0
> > > > > > release.
> > > > > > Please take a look and let me know if you want to add/modify
> > details.
> > > > > > Thanks to all who contributed to this blog post.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://blogs.apache.org/preview/kafka/?previewEntry=what-s-new-in-apache1
> > > > > >
> > > > > > Thanks,
> > > > > > Manikumar
> > > > > >
> > > > >
> > > >
> > >
>

Re: ClientsMetricsTest.shouldAddCommitIdMetric() failed on RC0 ...

[Eric Lalonde]

I see, thanks Bruno. 



> On Nov 19, 2019, at 12:24 AM, Bruno Cadonna  wrote:
> 
> Hi Eric,
> 
> With archive of the release candidate I mean:
> 
> https://home.apache.org/~manikumar/kafka-2.4.0-rc0/kafka-2.4.0-src.tgz
> or
> https://github.com/apache/kafka/archive/2.4.0-rc0.zip
> or
> https://github.com/apache/kafka/archive/2.4.0-rc0.tar.gz
> 
> If you used one of those and you ran into the failure my PR fixes the
> failure. If not, please let me know so that I can fix it.
> 
> Best,
> Bruno
> 
> On Tue, Nov 19, 2019 at 4:32 AM Eric Lalonde  wrote:
>> 
>> Bruno,
>> 
>> I tested using the 2.4.0 release candidate 0 artifacts. These were uploaded 
>> as part of seeking the open Kafka community feedback.
>> 
>> On Mon, Nov 18, 2019 at 12:24 PM Bruno Cadonna  wrote:
>>> 
>>> Hi Vahid and Eric,
>>> 
>>> Thank you for your input.
>>> 
>>> I suppose you both used the archive of the release candidate and did
>>> not checkout the tag from the git repository.
>>> 
>>> I found the issue. The archive misses the .git directory that is
>>> needed for the unit test to pass.
>>> 
>>> Opened the following PR to fix it: https://github.com/apache/kafka/pull/7707
>>> 
>>> Best,
>>> Bruno

[jira] [Created] (KAFKA-9211) kafka upgrade 2.3.0 cause produce speed decrease

[li xiangyuan (Jira)]

li xiangyuan created KAFKA-9211:
---

 Summary: kafka upgrade 2.3.0 cause produce speed decrease
 Key: KAFKA-9211
 URL: https://issues.apache.org/jira/browse/KAFKA-9211
 Project: Kafka
  Issue Type: Bug
  Components: controller, producer 
Affects Versions: 2.3.0
Reporter: li xiangyuan
 Attachments: broker-jstack.txt, producer-jstack.txt

Recently we try upgrade kafka from 0.10.0.1 to 2.3.0.

we have 15 clusters in production env, each one has 3~6 brokers.

we know kafka upgrade should:
      1.replcae code to 2.3.0.jar and restart  all brokers one by one
      2.unset inter.broker.protocol.version=0.10.0.1 and restart all brokers 
one by one
      3.unset log.message.format.version=0.10.0.1 and restart all brokers one 
by one
 
for now we have already done step 1 & 2 in 12 clusters.but when we try to 
upgrade left clusters (already done step 1) in step 2, we found some topics 
drop produce speed badly.
     we have research this issue for long time, since we couldn't test it in 
production environment  and we couldn't reproduce in test environment, we 
couldn't find the root cause.
now we only could describe the situation in detail as  i know, hope anyone 
could help us.
 
1.because bug KAFKA-8653, i add code below in KafkaApis.scala 
handleJoinGroupRequest function:
{code:java}
if (rebalanceTimeoutMs <= 0) {
 rebalanceTimeoutMs = joinGroupRequest.data.sessionTimeoutMs
}{code}

2.one cluster upgrade failed has 6 8C16G brokers, about 200 topics with 2 
replicas,every broker keep 3000+ partitions and 1500+ leader partition, but 
most of them has very low produce message speed,about less than 50messages/sec, 
only one topic with 300 partitions has more than 2500 message/sec with more 
than 20 consumer groups consume message from it.

so this whole cluster  produce 4K messages/sec , 11m Bytes in /sec,240m Bytes 
out /sec.and more than 90% traffic made by that topic has 2500messages/sec.

when we unset 5 or 6 servers' inter.broker.protocol.version=0.10.0.1  and 
restart, this topic produce message drop to about 200messages/sec,  i don't 
know whether the way we use could tirgger any problem.

3.we use kafka wrapped by spring-kafka and set kafkatemplate's autoFlush=true, 
so each producer.send execution will execute producer.flush immediately too.i 
know flush method will decrease produce performance dramaticlly, but  at least 
it seems nothing wrong before upgrade step 2. but i doubt whether it's a 
problem now after upgrade.

4.I noticed when produce speed decrease, some consumer group has large message 
lag still consume message without any consume speed change or decrease, so I 
guess only producerequest speed will drop down,but fetchrequest not. 

5.we haven't set any throttle configuration, and all producers' acks=1(so it's 
not broker replica fetch slow), and when this problem triggered, both sever & 
producers cpu usage down, and servers' ioutil keep less than 30% ,so it 
shuldn't be a hardware problem.

6.this event triggered often(almost 100%) most brokers has done upgrade step 
2,then after a auto leader replica election executed, then we can observe  
produce speed drop down,and we have to downgrade brokers(set 
inter.broker.protocol.version=0.10.0.1)and restart brokers one by one,then it 
could be normal. some cluster have to downgrade all brokers,but some cluster 
could left 1 or 2 brokers without downgrade, i notice that the broker not need 
downgrade is the controller.

7.I have print jstack for producer & servers. although I do this not the same 
cluster, but we can notice that their thread seems really in idle stat.

8.both 0.10.0.1 & 2.3.0 kafka-client will trigger this problem too.

8.unless the largest one topic will drop produce speed certainly, other topic 
will drop produce speed randomly. maybe topicA will drop speed in first upgrade 
attempt but next not, and topicB not drop speed in first attemp but dropped 
when do another attempt.

9.in fact, the largest cluster, has the same topic & group usage scenario 
mentioned above, but the largest topic has 1w2 messages/sec,will upgrade fail 
in step 1(just use 2.3.0.jar)


any help would be grateful, thx, i'm very sad now...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Build failed in Jenkins: kafka-trunk-jdk11 #967

[Apache Jenkins Server]

See 


Changes:

[matthias] HOTFIX: Fix unit tests that failed when executed from IDE (#7707)

[github] MINOR: Remove explicit version checks in getErrorResponse methods

[github] KAFKA-8981 Add rate limiting to NetworkDegradeSpec (#7446)


--
[...truncated 2.73 MB...]
org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestampWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentForCompareKeyValueTimestampWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueIsEqualWithNullForCompareValueWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueIsEqualWithNullForCompareValueWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfTimestampIsDifferentForCompareValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfTimestampIsDifferentForCompareValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualWithNullForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualWithNullForCompareKeyValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueWithProducerRecord STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestampWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestampWithProducerRecord PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordWithExpectedRecordForCompareValueTimestamp 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordWithExpectedRecordForCompareValueTimestamp 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullExpectedRecordForCompareValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullExpectedRecordForCompareValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareKeyValue STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldNotAllowNullProducerRecordForCompareKeyValue PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualForCompareKeyValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueAndTimestampIsEqualForCompareKeyValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullForCompareKeyValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 

Re: ClientsMetricsTest.shouldAddCommitIdMetric() failed on RC0 ...

[Bruno Cadonna]

Hi Eric,

With archive of the release candidate I mean:

https://home.apache.org/~manikumar/kafka-2.4.0-rc0/kafka-2.4.0-src.tgz
or
https://github.com/apache/kafka/archive/2.4.0-rc0.zip
or
https://github.com/apache/kafka/archive/2.4.0-rc0.tar.gz

If you used one of those and you ran into the failure my PR fixes the
failure. If not, please let me know so that I can fix it.

Best,
Bruno

On Tue, Nov 19, 2019 at 4:32 AM Eric Lalonde  wrote:
>
> Bruno,
>
> I tested using the 2.4.0 release candidate 0 artifacts. These were uploaded 
> as part of seeking the open Kafka community feedback.
>
> On Mon, Nov 18, 2019 at 12:24 PM Bruno Cadonna  wrote:
>>
>> Hi Vahid and Eric,
>>
>> Thank you for your input.
>>
>> I suppose you both used the archive of the release candidate and did
>> not checkout the tag from the git repository.
>>
>> I found the issue. The archive misses the .git directory that is
>> needed for the unit test to pass.
>>
>> Opened the following PR to fix it: https://github.com/apache/kafka/pull/7707
>>
>> Best,
>> Bruno