[jira] [Commented] (KAFKA-4332) kafka.api.UserQuotaTest.testThrottledProducerConsumer transient unit test failure

[Matthias J. Sax (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794365#comment-16794365
 ] 

Matthias J. Sax commented on KAFKA-4332:


Failed again: 
[https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/3279/testReport/junit/kafka.api/UserQuotaTest/testThrottledProducerConsumer/]

> kafka.api.UserQuotaTest.testThrottledProducerConsumer transient unit test 
> failure
> -
>
> Key: KAFKA-4332
> URL: https://issues.apache.org/jira/browse/KAFKA-4332
> Project: Kafka
>  Issue Type: Sub-task
>  Components: core, unit tests
>Affects Versions: 0.10.1.0, 2.3.0
>Reporter: Jun Rao
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0
>
>
> kafka.api.UserQuotaTest > testThrottledProducerConsumer FAILED
> java.lang.AssertionError: Should have been throttled



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-7965) Flaky Test ConsumerBounceTest#testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup

[Matthias J. Sax (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-7965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794369#comment-16794369
 ] 

Matthias J. Sax commented on KAFKA-7965:


One more: 
[https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/20397/testReport/junit/kafka.api/ConsumerBounceTest/testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup/]

org.scalatest.junit.JUnitTestFailedError: Should have received an class 
org.apache.kafka.common.errors.GroupMaxSizeReachedException during the cluster 
roll

> Flaky Test 
> ConsumerBounceTest#testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup
> 
>
> Key: KAFKA-7965
> URL: https://issues.apache.org/jira/browse/KAFKA-7965
> Project: Kafka
>  Issue Type: Bug
>  Components: clients, consumer, unit tests
>Affects Versions: 2.2.0, 2.3.0
>Reporter: Matthias J. Sax
>Assignee: Stanislav Kozlovski
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0, 2.2.1
>
>
> To get stable nightly builds for `2.2` release, I create tickets for all 
> observed test failures.
> [https://jenkins.confluent.io/job/apache-kafka-test/job/2.2/21/]
> {quote}java.lang.AssertionError: Received 0, expected at least 68 at 
> org.junit.Assert.fail(Assert.java:88) at 
> org.junit.Assert.assertTrue(Assert.java:41) at 
> kafka.api.ConsumerBounceTest.receiveAndCommit(ConsumerBounceTest.scala:557) 
> at 
> kafka.api.ConsumerBounceTest.$anonfun$testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup$1(ConsumerBounceTest.scala:320)
>  at 
> kafka.api.ConsumerBounceTest.$anonfun$testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup$1$adapted(ConsumerBounceTest.scala:319)
>  at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62) 
> at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55) 
> at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49) at 
> kafka.api.ConsumerBounceTest.testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup(ConsumerBounceTest.scala:319){quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-8115) Flaky Test CoordinatorTest#testTaskRequestWithOldStartMsGetsUpdated

[Matthias J. Sax (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794366#comment-16794366
 ] 

Matthias J. Sax commented on KAFKA-8115:


Failed again: 
[https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/3279/testReport/junit/org.apache.kafka.trogdor.coordinator/CoordinatorTest/testTaskRequestWithOldStartMsGetsUpdated/]

> Flaky Test CoordinatorTest#testTaskRequestWithOldStartMsGetsUpdated
> ---
>
> Key: KAFKA-8115
> URL: https://issues.apache.org/jira/browse/KAFKA-8115
> Project: Kafka
>  Issue Type: Bug
>  Components: core, unit tests
>Affects Versions: 2.3.0
>Reporter: Matthias J. Sax
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0
>
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/3254/testReport/junit/org.apache.kafka.trogdor.coordinator/CoordinatorTest/testTaskRequestWithOldStartMsGetsUpdated/]
> {quote}org.junit.runners.model.TestTimedOutException: test timed out after 
> 12 milliseconds at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native 
> Method) at 
> java.base@11.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
>  at 
> java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
>  at 
> java.base@11.0.1/java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1454)
>  at 
> java.base@11.0.1/java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:709)
>  at 
> app//org.apache.kafka.trogdor.rest.JsonRestServer.waitForShutdown(JsonRestServer.java:157)
>  at app//org.apache.kafka.trogdor.agent.Agent.waitForShutdown(Agent.java:123) 
> at 
> app//org.apache.kafka.trogdor.common.MiniTrogdorCluster.close(MiniTrogdorCluster.java:285)
>  at 
> app//org.apache.kafka.trogdor.coordinator.CoordinatorTest.testTaskRequestWithOldStartMsGetsUpdated(CoordinatorTest.java:596)
>  at 
> java.base@11.0.1/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) at 
> java.base@11.0.1/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base@11.0.1/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.base@11.0.1/java.lang.reflect.Method.invoke(Method.java:566) at 
> app//org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>  at 
> app//org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> app//org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>  at 
> app//org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at 
> app//org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:288)
>  at 
> app//org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:282)
>  at java.base@11.0.1/java.util.concurrent.FutureTask.run(FutureTask.java:264) 
> at java.base@11.0.1/java.lang.Thread.run(Thread.java:834){quote}
> STDOUT
> {quote}[2019-03-15 09:23:41,364] INFO Creating MiniTrogdorCluster with 
> agents: node02 and coordinator: node01 
> (org.apache.kafka.trogdor.common.MiniTrogdorCluster:135) [2019-03-15 
> 09:23:41,595] INFO Logging initialized @13340ms to 
> org.eclipse.jetty.util.log.Slf4jLog (org.eclipse.jetty.util.log:193) 
> [2019-03-15 09:23:41,752] INFO Starting REST server 
> (org.apache.kafka.trogdor.rest.JsonRestServer:89) [2019-03-15 09:23:41,912] 
> INFO Registered resource 
> org.apache.kafka.trogdor.agent.AgentRestResource@3fa38ceb 
> (org.apache.kafka.trogdor.rest.JsonRestServer:94) [2019-03-15 09:23:42,178] 
> INFO jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; git: 
> c4550056e785fb5665914545889f21dc136ad9e6; jvm 11.0.1+13-LTS 
> (org.eclipse.jetty.server.Server:370) [2019-03-15 09:23:42,360] INFO 
> DefaultSessionIdManager workerName=node0 
> (org.eclipse.jetty.server.session:365) [2019-03-15 09:23:42,362] INFO No 
> SessionScavenger set, using defaults (org.eclipse.jetty.server.session:370) 
> [2019-03-15 09:23:42,370] INFO node0 Scavenging every 66ms 
> (org.eclipse.jetty.server.session:149) [2019-03-15 09:23:44,412] INFO Started 
> o.e.j.s.ServletContextHandler@335a5293\{/,null,AVAILABLE} 
> (org.eclipse.jetty.server.handler.ContextHandler:855) [2019-03-15 
> 09:23:44,473] INFO Started 
> ServerConnector@79a93bf1\{HTTP/1.1,[http/1.1]}{0.0.0.0:33477} 
> (org.eclipse.jetty.server.AbstractConnector:292) [2019-03-15 09:23:44,474] 
> INFO Started @16219ms (org.eclipse.jetty.server.Server:407) [2019-03-15 
> 09:23:44,475] INFO REST server listening at [http://127.0.1.1:33477/] 
> 

[jira] [Commented] (KAFKA-8030) Flaky Test TopicCommandWithAdminClientTest#testDescribeUnderMinIsrPartitionsMixed

[Matthias J. Sax (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794364#comment-16794364
 ] 

Matthias J. Sax commented on KAFKA-8030:


Again: 
[https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/3279/testReport/junit/kafka.admin/TopicCommandWithAdminClientTest/testDescribeUnderMinIsrPartitionsMixed/]

> Flaky Test 
> TopicCommandWithAdminClientTest#testDescribeUnderMinIsrPartitionsMixed
> -
>
> Key: KAFKA-8030
> URL: https://issues.apache.org/jira/browse/KAFKA-8030
> Project: Kafka
>  Issue Type: Bug
>  Components: admin, unit tests
>Affects Versions: 2.3.0
>Reporter: Matthias J. Sax
>Assignee: Viktor Somogyi-Vass
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0
>
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/2830/testReport/junit/kafka.admin/TopicCommandWithAdminClientTest/testDescribeUnderMinIsrPartitionsMixed/]
> {quote}java.lang.AssertionError at org.junit.Assert.fail(Assert.java:87) at 
> org.junit.Assert.assertTrue(Assert.java:42) at 
> org.junit.Assert.assertTrue(Assert.java:53) at 
> kafka.admin.TopicCommandWithAdminClientTest.testDescribeUnderMinIsrPartitionsMixed(TopicCommandWithAdminClientTest.scala:602){quote}
> STDERR
> {quote}Option "[replica-assignment]" can't be used with option 
> "[partitions]"{quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-8030) Flaky Test TopicCommandWithAdminClientTest#testDescribeUnderMinIsrPartitionsMixed

[Matthias J. Sax (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794351#comment-16794351
 ] 

Matthias J. Sax commented on KAFKA-8030:


One more: 
[https://builds.apache.org/blue/organizations/jenkins/kafka-trunk-jdk8/detail/kafka-trunk-jdk8/3471/tests]

> Flaky Test 
> TopicCommandWithAdminClientTest#testDescribeUnderMinIsrPartitionsMixed
> -
>
> Key: KAFKA-8030
> URL: https://issues.apache.org/jira/browse/KAFKA-8030
> Project: Kafka
>  Issue Type: Bug
>  Components: admin, unit tests
>Affects Versions: 2.3.0
>Reporter: Matthias J. Sax
>Assignee: Viktor Somogyi-Vass
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0
>
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/2830/testReport/junit/kafka.admin/TopicCommandWithAdminClientTest/testDescribeUnderMinIsrPartitionsMixed/]
> {quote}java.lang.AssertionError at org.junit.Assert.fail(Assert.java:87) at 
> org.junit.Assert.assertTrue(Assert.java:42) at 
> org.junit.Assert.assertTrue(Assert.java:53) at 
> kafka.admin.TopicCommandWithAdminClientTest.testDescribeUnderMinIsrPartitionsMixed(TopicCommandWithAdminClientTest.scala:602){quote}
> STDERR
> {quote}Option "[replica-assignment]" can't be used with option 
> "[partitions]"{quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-8117) Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoProduceWithDescribeAcl

[Matthias J. Sax (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794350#comment-16794350
 ] 

Matthias J. Sax commented on KAFKA-8117:


[~omkreddy], [~rsivaram]: the stack trace if different so I am not sure if the 
latest fix of KAFKA-8114 would address this, too. Thus, I created a new ticket. 
If you think it fixed with KAFKA-8114, just close this ticket.

> Flaky Test 
> DelegationTokenEndToEndAuthorizationTest#testNoProduceWithDescribeAcl
> 
>
> Key: KAFKA-8117
> URL: https://issues.apache.org/jira/browse/KAFKA-8117
> Project: Kafka
>  Issue Type: Bug
>  Components: core, unit tests
>Affects Versions: 2.3.0
>Reporter: Matthias J. Sax
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0
>
>
> [https://builds.apache.org/blue/organizations/jenkins/kafka-trunk-jdk8/detail/kafka-trunk-jdk8/3470/tests]
> {quote}java.util.concurrent.ExecutionException: 
> org.apache.kafka.common.errors.SaslAuthenticationException: Authentication 
> failed during authentication due to invalid credentials with SASL mechanism 
> SCRAM-SHA-256
> at 
> org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
> at 
> org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
> at 
> org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
> at 
> org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
> at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.createDelegationToken(DelegationTokenEndToEndAuthorizationTest.scala:88)
> at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.configureSecurityAfterServersStart(DelegationTokenEndToEndAuthorizationTest.scala:63)
> at 
> kafka.integration.KafkaServerTestHarness.setUp(KafkaServerTestHarness.scala:107)
> at kafka.api.IntegrationTestHarness.doSetup(IntegrationTestHarness.scala:81)
> at kafka.api.IntegrationTestHarness.setUp(IntegrationTestHarness.scala:73)
> at 
> kafka.api.EndToEndAuthorizationTest.setUp(EndToEndAuthorizationTest.scala:183)
> at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.setUp(DelegationTokenEndToEndAuthorizationTest.scala:74){quote}
> STDOUT
> {quote}Adding ACLs for resource `Cluster:LITERAL:kafka-cluster`:
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: *
>  
> Current ACLs for resource `Cluster:LITERAL:kafka-cluster`:
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: *
>  
> Adding ACLs for resource `Topic:LITERAL:*`:
> User:scram-admin has Allow permission for operations: Read from hosts: *
>  
> Current ACLs for resource `Topic:LITERAL:*`:
> User:scram-admin has Allow permission for operations: Read from hosts: *
>  
> Completed Updating config for entity: user-principal 'scram-admin'.
> Completed Updating config for entity: user-principal 'scram-user'.
> Adding ACLs for resource `Topic:LITERAL:e2etopic`:
> User:scram-user has Allow permission for operations: Write from hosts: *
> User:scram-user has Allow permission for operations: Create from hosts: *
> User:scram-user has Allow permission for operations: Describe from hosts: *
>  
> Current ACLs for resource `Topic:LITERAL:e2etopic`:
> User:scram-user has Allow permission for operations: Write from hosts: *
> User:scram-user has Allow permission for operations: Create from hosts: *
> User:scram-user has Allow permission for operations: Describe from hosts: *
>  
> Adding ACLs for resource `Group:LITERAL:group`:
> User:scram-user has Allow permission for operations: Read from hosts: *
>  
> Current ACLs for resource `Group:LITERAL:group`:
> User:scram-user has Allow permission for operations: Read from hosts: *
>  
> Current ACLs for resource `Topic:LITERAL:e2etopic`:
> User:scram-user has Allow permission for operations: Write from hosts: *
> User:scram-user has Allow permission for operations: Create from hosts: *
>  
> Current ACLs for resource `Topic:LITERAL:e2etopic`:
> User:scram-user has Allow permission for operations: Create from hosts: *
>  
> [2019-03-16 03:39:08,540] WARN Unable to read additional data from client 
> sessionid 0x1045892126e0013, likely client has closed socket 
> (org.apache.zookeeper.server.NIOServerCnxn:376)
> [2019-03-16 03:39:08,634] ERROR [Consumer clientId=consumer-21, 
> groupId=group] Topic authorization failed for topics [e2etopic] 
> (org.apache.kafka.clients.Metadata:297)
> Adding ACLs for resource `Cluster:LITERAL:kafka-cluster`:
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: *
>  
> Current ACLs for resource `Cluster:LITERAL:kafka-cluster`:
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: 

[jira] [Created] (KAFKA-8117) Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoProduceWithDescribeAcl

[Matthias J. Sax (JIRA)]

Matthias J. Sax created KAFKA-8117:
--

 Summary: Flaky Test 
DelegationTokenEndToEndAuthorizationTest#testNoProduceWithDescribeAcl
 Key: KAFKA-8117
 URL: https://issues.apache.org/jira/browse/KAFKA-8117
 Project: Kafka
  Issue Type: Bug
  Components: core, unit tests
Affects Versions: 2.3.0
Reporter: Matthias J. Sax
 Fix For: 2.3.0


[https://builds.apache.org/blue/organizations/jenkins/kafka-trunk-jdk8/detail/kafka-trunk-jdk8/3470/tests]
{quote}java.util.concurrent.ExecutionException: 
org.apache.kafka.common.errors.SaslAuthenticationException: Authentication 
failed during authentication due to invalid credentials with SASL mechanism 
SCRAM-SHA-256
at 
org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
at 
org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
at 
org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
at 
org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
at 
kafka.api.DelegationTokenEndToEndAuthorizationTest.createDelegationToken(DelegationTokenEndToEndAuthorizationTest.scala:88)
at 
kafka.api.DelegationTokenEndToEndAuthorizationTest.configureSecurityAfterServersStart(DelegationTokenEndToEndAuthorizationTest.scala:63)
at 
kafka.integration.KafkaServerTestHarness.setUp(KafkaServerTestHarness.scala:107)
at kafka.api.IntegrationTestHarness.doSetup(IntegrationTestHarness.scala:81)
at kafka.api.IntegrationTestHarness.setUp(IntegrationTestHarness.scala:73)
at 
kafka.api.EndToEndAuthorizationTest.setUp(EndToEndAuthorizationTest.scala:183)
at 
kafka.api.DelegationTokenEndToEndAuthorizationTest.setUp(DelegationTokenEndToEndAuthorizationTest.scala:74){quote}
STDOUT
{quote}Adding ACLs for resource `Cluster:LITERAL:kafka-cluster`:
User:scram-admin has Allow permission for operations: ClusterAction from hosts: 
*
 
Current ACLs for resource `Cluster:LITERAL:kafka-cluster`:
User:scram-admin has Allow permission for operations: ClusterAction from hosts: 
*
 
Adding ACLs for resource `Topic:LITERAL:*`:
User:scram-admin has Allow permission for operations: Read from hosts: *
 
Current ACLs for resource `Topic:LITERAL:*`:
User:scram-admin has Allow permission for operations: Read from hosts: *
 
Completed Updating config for entity: user-principal 'scram-admin'.
Completed Updating config for entity: user-principal 'scram-user'.
Adding ACLs for resource `Topic:LITERAL:e2etopic`:
User:scram-user has Allow permission for operations: Write from hosts: *
User:scram-user has Allow permission for operations: Create from hosts: *
User:scram-user has Allow permission for operations: Describe from hosts: *
 
Current ACLs for resource `Topic:LITERAL:e2etopic`:
User:scram-user has Allow permission for operations: Write from hosts: *
User:scram-user has Allow permission for operations: Create from hosts: *
User:scram-user has Allow permission for operations: Describe from hosts: *
 
Adding ACLs for resource `Group:LITERAL:group`:
User:scram-user has Allow permission for operations: Read from hosts: *
 
Current ACLs for resource `Group:LITERAL:group`:
User:scram-user has Allow permission for operations: Read from hosts: *
 
Current ACLs for resource `Topic:LITERAL:e2etopic`:
User:scram-user has Allow permission for operations: Write from hosts: *
User:scram-user has Allow permission for operations: Create from hosts: *
 
Current ACLs for resource `Topic:LITERAL:e2etopic`:
User:scram-user has Allow permission for operations: Create from hosts: *
 
[2019-03-16 03:39:08,540] WARN Unable to read additional data from client 
sessionid 0x1045892126e0013, likely client has closed socket 
(org.apache.zookeeper.server.NIOServerCnxn:376)
[2019-03-16 03:39:08,634] ERROR [Consumer clientId=consumer-21, groupId=group] 
Topic authorization failed for topics [e2etopic] 
(org.apache.kafka.clients.Metadata:297)
Adding ACLs for resource `Cluster:LITERAL:kafka-cluster`:
User:scram-admin has Allow permission for operations: ClusterAction from hosts: 
*
 
Current ACLs for resource `Cluster:LITERAL:kafka-cluster`:
User:scram-admin has Allow permission for operations: ClusterAction from hosts: 
*
 
Adding ACLs for resource `Topic:LITERAL:*`:
User:scram-admin has Allow permission for operations: Read from hosts: *
 
Current ACLs for resource `Topic:LITERAL:*`:
User:scram-admin has Allow permission for operations: Read from hosts: *
 
Completed Updating config for entity: user-principal 'scram-admin'.
Completed Updating config for entity: user-principal 'scram-user'.
Adding ACLs for resource `Topic:PREFIXED:e2e`:
User:scram-user has Allow permission for operations: Read from hosts: *
User:scram-user has Allow permission for operations: Describe from hosts: *
User:scram-user has Allow permission for operations: Write from hosts: *
User:scram-user has Allow permission for 

[jira] [Commented] (KAFKA-5998) /.checkpoint.tmp Not found exception

[Jesse WHite (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794330#comment-16794330
 ] 

Jesse WHite commented on KAFKA-5998:


We're running into this one too:
{noformat}
2019-03-16T14:46:50,866 | WARN  | 
oce-datasource-33a4a7f6-b157-4b31-abc7-f21939543865-StreamThread-7 | 
ProcessorStateManager| 82 - 
org.apache.servicemix.bundles.kafka-clients - 2.0.0.1 | task [2_0] Failed to 
write offset checkpoint file to 
/opt/sentinel/data/kafka/oce-datasource/2_0/.checkpoint: {}
java.io.FileNotFoundException: 
/opt/sentinel/data/kafka/oce-datasource/2_0/.checkpoint.tmp (No such file or 
directory)
at java.io.FileOutputStream.open0(Native Method) ~[?:?]
at java.io.FileOutputStream.open(FileOutputStream.java:270) ~[?:?]
at java.io.FileOutputStream.(FileOutputStream.java:213) ~[?:?]
at java.io.FileOutputStream.(FileOutputStream.java:162) ~[?:?]
at 
org.apache.kafka.streams.state.internals.OffsetCheckpoint.write(OffsetCheckpoint.java:78)
 ~[83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.ProcessorStateManager.checkpoint(ProcessorStateManager.java:315)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.StreamTask.commit(StreamTask.java:383)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.StreamTask.commit(StreamTask.java:368)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.AssignedTasks$1.apply(AssignedTasks.java:67)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.AssignedTasks.applyToRunningTasks(AssignedTasks.java:362)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.AssignedTasks.commit(AssignedTasks.java:352)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.TaskManager.commitAll(TaskManager.java:401)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.StreamThread.maybeCommit(StreamThread.java:1035)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:845)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:767)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
at 
org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:736)
 [83:org.apache.servicemix.bundles.kafka-streams:2.0.0.1]
{noformat}


> /.checkpoint.tmp Not found exception
> 
>
> Key: KAFKA-5998
> URL: https://issues.apache.org/jira/browse/KAFKA-5998
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 0.11.0.0, 0.11.0.1, 2.1.1
>Reporter: Yogesh BG
>Priority: Major
> Attachments: 5998.v1.txt, 5998.v2.txt, Topology.txt, exc.txt, 
> props.txt, streams.txt
>
>
> I have one kafka broker and one kafka stream running... I am running its 
> since two days under load of around 2500 msgs per second.. On third day am 
> getting below exception for some of the partitions, I have 16 partitions only 
> 0_0 and 0_1 gives this error
> {{09:43:25.955 [ks_0_inst-StreamThread-6] WARN  
> o.a.k.s.p.i.ProcessorStateManager - Failed to write checkpoint file to 
> /data/kstreams/rtp-kafkastreams/0_1/.checkpoint:
> java.io.FileNotFoundException: 
> /data/kstreams/rtp-kafkastreams/0_1/.checkpoint.tmp (No such file or 
> directory)
> at java.io.FileOutputStream.open(Native Method) ~[na:1.7.0_111]
> at java.io.FileOutputStream.(FileOutputStream.java:221) 
> ~[na:1.7.0_111]
> at java.io.FileOutputStream.(FileOutputStream.java:171) 
> ~[na:1.7.0_111]
> at 
> org.apache.kafka.streams.state.internals.OffsetCheckpoint.write(OffsetCheckpoint.java:73)
>  ~[rtp-kafkastreams-1.0-SNAPSHOT-jar-with-dependencies.jar:na]
> at 
> org.apache.kafka.streams.processor.internals.ProcessorStateManager.checkpoint(ProcessorStateManager.java:324)
>  ~[rtp-kafkastreams-1.0-SNAPSHOT-jar-with-dependencies.jar:na]
> at 
> org.apache.kafka.streams.processor.internals.StreamTask$1.run(StreamTask.java:267)
>  [rtp-kafkastreams-1.0-SNAPSHOT-jar-with-dependencies.jar:na]
> at 
> org.apache.kafka.streams.processor.internals.StreamsMetricsImpl.measureLatencyNs(StreamsMetricsImpl.java:201)
>  [rtp-kafkastreams-1.0-SNAPSHOT-jar-with-dependencies.jar:na]
> at 
> 

[jira] [Commented] (KAFKA-3539) KafkaProducer.send() may block even though it returns the Future

[Spyridon Ninos (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794322#comment-16794322
 ] 

Spyridon Ninos commented on KAFKA-3539:
---

Hi [~ozhurakousky],

 given that the PR you created for this change is closed, and it seems that 
there is no intention to work on the idea, should we also close the ticket?

 

Thanks

> KafkaProducer.send() may block even though it returns the Future
> 
>
> Key: KAFKA-3539
> URL: https://issues.apache.org/jira/browse/KAFKA-3539
> Project: Kafka
>  Issue Type: Bug
>  Components: producer 
>Reporter: Oleg Zhurakousky
>Priority: Critical
>
> You can get more details from the us...@kafka.apache.org by searching on the 
> thread with the subject "KafkaProducer block on send".
> The bottom line is that method that returns Future must never block, since it 
> essentially violates the Future contract as it was specifically designed to 
> return immediately passing control back to the user to check for completion, 
> cancel etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (KAFKA-8114) Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoGroupAcl

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram resolved KAFKA-8114.
---
   Resolution: Fixed
 Assignee: Manikumar
 Reviewer: Rajini Sivaram
Fix Version/s: 2.2.1

> Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoGroupAcl
> --
>
> Key: KAFKA-8114
> URL: https://issues.apache.org/jira/browse/KAFKA-8114
> Project: Kafka
>  Issue Type: Bug
>  Components: core, unit tests
>Affects Versions: 2.3.0
>Reporter: Matthias J. Sax
>Assignee: Manikumar
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0, 2.2.1
>
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/3254/testReport/junit/kafka.api/DelegationTokenEndToEndAuthorizationTest/testNoGroupAcl/]
> {quote}java.util.concurrent.ExecutionException: 
> org.apache.kafka.common.errors.SaslAuthenticationException: Authentication 
> failed during authentication due to invalid credentials with SASL mechanism 
> SCRAM-SHA-256 at 
> org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.createDelegationToken(DelegationTokenEndToEndAuthorizationTest.scala:88)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.configureSecurityAfterServersStart(DelegationTokenEndToEndAuthorizationTest.scala:63)
>  at 
> kafka.integration.KafkaServerTestHarness.setUp(KafkaServerTestHarness.scala:107)
>  at kafka.api.IntegrationTestHarness.doSetup(IntegrationTestHarness.scala:81) 
> at kafka.api.IntegrationTestHarness.setUp(IntegrationTestHarness.scala:73) at 
> kafka.api.EndToEndAuthorizationTest.setUp(EndToEndAuthorizationTest.scala:183)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.setUp(DelegationTokenEndToEndAuthorizationTest.scala:74){quote}
> STDOUT
> {quote}Adding ACLs for resource `Cluster:LITERAL:kafka-cluster`: 
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: * Current ACLs for resource `Cluster:LITERAL:kafka-cluster`: 
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: * Adding ACLs for resource `Topic:LITERAL:*`: User:scram-admin has 
> Allow permission for operations: Read from hosts: * Current ACLs for resource 
> `Topic:LITERAL:*`: User:scram-admin has Allow permission for operations: Read 
> from hosts: * Completed Updating config for entity: user-principal 
> 'scram-admin'. Completed Updating config for entity: user-principal 
> 'scram-user'. Adding ACLs for resource `Topic:LITERAL:e2etopic`: 
> User:scram-user has Allow permission for operations: Write from hosts: * 
> User:scram-user has Allow permission for operations: Create from hosts: * 
> User:scram-user has Allow permission for operations: Describe from hosts: * 
> Current ACLs for resource `Topic:LITERAL:e2etopic`: User:scram-user has Allow 
> permission for operations: Write from hosts: * User:scram-user has Allow 
> permission for operations: Create from hosts: * User:scram-user has Allow 
> permission for operations: Describe from hosts: * Adding ACLs for resource 
> `Group:LITERAL:group`: User:scram-user has Allow permission for operations: 
> Read from hosts: * Current ACLs for resource `Group:LITERAL:group`: 
> User:scram-user has Allow permission for operations: Read from hosts: * 
> Current ACLs for resource `Topic:LITERAL:e2etopic`: User:scram-user has Allow 
> permission for operations: Write from hosts: * User:scram-user has Allow 
> permission for operations: Create from hosts: * Current ACLs for resource 
> `Topic:LITERAL:e2etopic`: User:scram-user has Allow permission for 
> operations: Create from hosts: * [2019-03-15 09:58:16,481] ERROR [Consumer 
> clientId=consumer-99, groupId=group] Topic authorization failed for topics 
> [e2etopic] (org.apache.kafka.clients.Metadata:297) [2019-03-15 09:58:17,527] 
> WARN Unable to read additional data from client sessionid 0x104549c2b88000a, 
> likely client has closed socket 
> (org.apache.zookeeper.server.NIOServerCnxn:376) Adding ACLs for resource 
> `Cluster:LITERAL:kafka-cluster`: User:scram-admin has Allow permission for 
> operations: ClusterAction from hosts: * Current ACLs for resource 
> `Cluster:LITERAL:kafka-cluster`: User:scram-admin has Allow permission for 
> operations: ClusterAction from hosts: * Adding ACLs for resource 
> `Topic:LITERAL:*`: User:scram-admin has Allow permission for operations: Read 
> from hosts: * Current 

[jira] [Resolved] (KAFKA-8111) KafkaProducer can't produce data

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram resolved KAFKA-8111.
---
   Resolution: Fixed
 Reviewer: Manikumar
Fix Version/s: 2.3.0

> KafkaProducer can't produce data
> 
>
> Key: KAFKA-8111
> URL: https://issues.apache.org/jira/browse/KAFKA-8111
> Project: Kafka
>  Issue Type: Bug
>  Components: clients, core
>Affects Versions: 2.3.0
>Reporter: John Roesler
>Assignee: Rajini Sivaram
>Priority: Critical
>  Labels: blocker
> Fix For: 2.3.0
>
>
> Using a Producer from the current trunk (a6691fb79), I'm unable to produce 
> data to a 2.2 broker.
> tl;dr;, I narrowed down the problem to 
> [https://github.com/apache/kafka/commit/a42f16f98] . My hypothesis is that 
> some part of that commit broke backward compatibility with older brokers.
>  
> Repro steps:
> I'm using this Producer config:
> {noformat}
> final Properties properties = new Properties();
> properties.setProperty(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, BROKER);
> properties.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, 
> StringSerializer.class.getCanonicalName());
> properties.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, 
> StringSerializer.class.getCanonicalName());
> return properties;{noformat}
>  # create a simple Producer to produce test data to a broker
>  # build against commmit a42f16f98 
>  # start an older broker. (I was using 2.1, and someone else reproduced it 
> with 2.2)
>  # run your producer and note that it doesn't produce data (seems to hang, I 
> see it produce 2 records in 1 minute)
>  # build against the predecessor commit 65aea1f36
>  # run your producer and note that it DOES produce data (I see it produce 1M 
> records every 15 second)
> I've also confirmed that if I check out the current trunk (a6691fb79e2c55b3) 
> and revert a42f16f98, I also observe that it produces as expected (1M every 
> 15 seconds).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-8114) Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoGroupAcl

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794217#comment-16794217
 ] 

ASF GitHub Bot commented on KAFKA-8114:
---

rajinisivaram commented on pull request #6452: KAFKA-8114: Wait for SCRAM 
credential propagation in DelegationTokenEdToEndAuthorizationTest
URL: https://github.com/apache/kafka/pull/6452
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoGroupAcl
> --
>
> Key: KAFKA-8114
> URL: https://issues.apache.org/jira/browse/KAFKA-8114
> Project: Kafka
>  Issue Type: Bug
>  Components: core, unit tests
>Affects Versions: 2.3.0
>Reporter: Matthias J. Sax
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0
>
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/3254/testReport/junit/kafka.api/DelegationTokenEndToEndAuthorizationTest/testNoGroupAcl/]
> {quote}java.util.concurrent.ExecutionException: 
> org.apache.kafka.common.errors.SaslAuthenticationException: Authentication 
> failed during authentication due to invalid credentials with SASL mechanism 
> SCRAM-SHA-256 at 
> org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.createDelegationToken(DelegationTokenEndToEndAuthorizationTest.scala:88)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.configureSecurityAfterServersStart(DelegationTokenEndToEndAuthorizationTest.scala:63)
>  at 
> kafka.integration.KafkaServerTestHarness.setUp(KafkaServerTestHarness.scala:107)
>  at kafka.api.IntegrationTestHarness.doSetup(IntegrationTestHarness.scala:81) 
> at kafka.api.IntegrationTestHarness.setUp(IntegrationTestHarness.scala:73) at 
> kafka.api.EndToEndAuthorizationTest.setUp(EndToEndAuthorizationTest.scala:183)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.setUp(DelegationTokenEndToEndAuthorizationTest.scala:74){quote}
> STDOUT
> {quote}Adding ACLs for resource `Cluster:LITERAL:kafka-cluster`: 
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: * Current ACLs for resource `Cluster:LITERAL:kafka-cluster`: 
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: * Adding ACLs for resource `Topic:LITERAL:*`: User:scram-admin has 
> Allow permission for operations: Read from hosts: * Current ACLs for resource 
> `Topic:LITERAL:*`: User:scram-admin has Allow permission for operations: Read 
> from hosts: * Completed Updating config for entity: user-principal 
> 'scram-admin'. Completed Updating config for entity: user-principal 
> 'scram-user'. Adding ACLs for resource `Topic:LITERAL:e2etopic`: 
> User:scram-user has Allow permission for operations: Write from hosts: * 
> User:scram-user has Allow permission for operations: Create from hosts: * 
> User:scram-user has Allow permission for operations: Describe from hosts: * 
> Current ACLs for resource `Topic:LITERAL:e2etopic`: User:scram-user has Allow 
> permission for operations: Write from hosts: * User:scram-user has Allow 
> permission for operations: Create from hosts: * User:scram-user has Allow 
> permission for operations: Describe from hosts: * Adding ACLs for resource 
> `Group:LITERAL:group`: User:scram-user has Allow permission for operations: 
> Read from hosts: * Current ACLs for resource `Group:LITERAL:group`: 
> User:scram-user has Allow permission for operations: Read from hosts: * 
> Current ACLs for resource `Topic:LITERAL:e2etopic`: User:scram-user has Allow 
> permission for operations: Write from hosts: * User:scram-user has Allow 
> permission for operations: Create from hosts: * Current ACLs for resource 
> `Topic:LITERAL:e2etopic`: User:scram-user has Allow permission for 
> operations: Create from hosts: * [2019-03-15 09:58:16,481] ERROR [Consumer 
> clientId=consumer-99, groupId=group] Topic authorization failed for topics 
> [e2etopic] (org.apache.kafka.clients.Metadata:297) [2019-03-15 09:58:17,527] 
> WARN Unable to read additional data from client sessionid 0x104549c2b88000a, 
> likely client has closed socket 
> (org.apache.zookeeper.server.NIOServerCnxn:376) Adding ACLs for 

[jira] [Commented] (KAFKA-8111) KafkaProducer can't produce data

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794215#comment-16794215
 ] 

ASF GitHub Bot commented on KAFKA-8111:
---

rajinisivaram commented on pull request #6451: KAFKA-8111; Set min and max 
versions for Metadata requests
URL: https://github.com/apache/kafka/pull/6451
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> KafkaProducer can't produce data
> 
>
> Key: KAFKA-8111
> URL: https://issues.apache.org/jira/browse/KAFKA-8111
> Project: Kafka
>  Issue Type: Bug
>  Components: clients, core
>Affects Versions: 2.3.0
>Reporter: John Roesler
>Assignee: Rajini Sivaram
>Priority: Critical
>  Labels: blocker
>
> Using a Producer from the current trunk (a6691fb79), I'm unable to produce 
> data to a 2.2 broker.
> tl;dr;, I narrowed down the problem to 
> [https://github.com/apache/kafka/commit/a42f16f98] . My hypothesis is that 
> some part of that commit broke backward compatibility with older brokers.
>  
> Repro steps:
> I'm using this Producer config:
> {noformat}
> final Properties properties = new Properties();
> properties.setProperty(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, BROKER);
> properties.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, 
> StringSerializer.class.getCanonicalName());
> properties.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, 
> StringSerializer.class.getCanonicalName());
> return properties;{noformat}
>  # create a simple Producer to produce test data to a broker
>  # build against commmit a42f16f98 
>  # start an older broker. (I was using 2.1, and someone else reproduced it 
> with 2.2)
>  # run your producer and note that it doesn't produce data (seems to hang, I 
> see it produce 2 records in 1 minute)
>  # build against the predecessor commit 65aea1f36
>  # run your producer and note that it DOES produce data (I see it produce 1M 
> records every 15 second)
> I've also confirmed that if I check out the current trunk (a6691fb79e2c55b3) 
> and revert a42f16f98, I also observe that it produces as expected (1M every 
> 15 seconds).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-7502) Cleanup KTable materialization logic in a single place

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794205#comment-16794205
 ] 

ASF GitHub Bot commented on KAFKA-7502:
---

dongjinleekr commented on pull request #6453: KAFKA-7502: Cleanup KTable 
materialization logic in a single place
URL: https://github.com/apache/kafka/pull/6453
 
 
   This PR is a follow-up of #6174, which handles `doFilter` method.
   
   cc/ @guozhangwang @bbejeck
   
   ### Committer Checklist (excluded from commit message)
   - [ ] Verify design and implementation 
   - [ ] Verify test coverage and CI build status
   - [ ] Verify documentation (including upgrade notes)
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Cleanup KTable materialization logic in a single place
> --
>
> Key: KAFKA-7502
> URL: https://issues.apache.org/jira/browse/KAFKA-7502
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Reporter: Guozhang Wang
>Assignee: Lee Dongjin
>Priority: Major
>
> Today since we pre-create all the `KTableXXX` operator along with the logical 
> node, we are effectively duplicating the logic to determine whether the 
> resulted KTable should be materialized. More specifically, the 
> materialization principle today is that:
> 1) If users specified Materialized in the DSL and it contains a queryable 
> name. We always materialize.
> 2) If users specified Materialized in the DSL but not contains a queryable 
> name, or if users do not specify a Materialized object at all, Streams may 
> choose to materialize or not. But in any cases, even if the KTable is 
> materialized it will not be queryable since there's no queryable name (i.e. 
> only storeName is not null, but queryableName is null):
> 2.a) If the resulted KTable is from an aggregation, we always materialize 
> since it is needed for storing the aggregation (i.e. we use the 
> MaterializedInternal constructor with nameProvider != null).
> 2.b) If the resulted KTable is from a source topic, we delay the 
> materialization until the downstream operator requires this KTable to be 
> materialized or send-old-values (see `KTableSourceNode` and `KTableSource`).
> 2.c) If the resulted KTable if from a join, we always materialize if users 
> creates a Materialized object even without a queryable name. However this can 
> be optimized similar to 2.b) but is orthogonal to this ticket (see 
> `KTableImpl#buildJoin` where we always use constructor with nameProvider != 
> null).
> 2.d) If the resulted KTable is from a stateless operation like filter / 
> mapValues, we never materialize.
> 
> Now, in all of these cases, we have logical node like "KTableKTableJoinNode", 
> as well as physical node like `ProcessorNode`. Ideally we should always 
> create the logical Plan (i.e. the StreamsGraph), and then optimize it if 
> necessary, and then generate the physical plan (i.e. the Topology), however 
> today we create some physical nodes beforehand, and the above logic is hence 
> duplicated in the creation of both physical nodes and logical nodes. For 
> example, in `KTableKTableJoinNode` we check if Materialized is null for 
> adding a state store, and in `KTableImpl#doJoin` we check if materialized is 
> specified (case 2.c) above). 
> Another example is in TableProcessorNode which is used for 2.d) above, in 
> which it includes the logic whereas its caller, `KTableImpl#doFilter` for 
> example, also contains the logic when deciding to pass `queryableName` 
> parameter to `KTableProcessorSupplier`.
> This is bug-vulnerable since we may update the logic in one class but forgot 
> to update the other class.
> --
> What we want to have is a cleaner code path similar to what we have for 2.b), 
> such that when creating the logical nodes we keep track of whether 1) 
> materialized is specified, and 2) queryable name is provided. And during 
> optimization phase, we may change the inner physical ProcessorBuilder's 
> parameters like queryable name etc, and then when it is time to generate the 
> physical node, we can just blindly take the parameters and go for it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[Flower.min (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794193#comment-16794193
 ] 

Flower.min edited comment on KAFKA-8106 at 3/16/19 9:18 AM:


 My team and I modify some code of Kafka  and I need permission to commit Code. 
We do performance testing again with package include of modified code .The 
performance of production improved by 40%~50%,and resource usage of CPU reduced 
by 30%~50%.


was (Author: flower.min):
I and My team modify some code of Kafka  and I need permission to commit Code. 
We do performance testing again with package include of modified code .the 
result of perfoemance testing is shown as below.The performance of production 
improved by 40%~50%,and resource usage of CPU reduced by 30%~50%.

> Remove unnecessary decompression operation when logValidator  do validation.
> 
>
> Key: KAFKA-8106
> URL: https://issues.apache.org/jira/browse/KAFKA-8106
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.1.1
> Environment: Server : 
> cpu:2*16 ; 
> MemTotal : 256G;
> Ethernet controller:Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network 
> Connection ; 
> SSD.
>Reporter: Flower.min
>Priority: Major
>  Labels: performance
>
>       We do performance testing about Kafka in specific scenarios as 
> described below .We build a kafka cluster with one broker,and create topics 
> with different number of partitions.Then we start lots of producer processes 
> to send large amounts of messages to one of the topics at one  testing .
> *_Specific Scenario_*
>   
>  *_1.Main config of Kafka_*  
>  # Main config of Kafka  
> server:[num.network.threads=6;num.io.threads=128;queued.max.requests=500|http://num.network.threads%3D6%3Bnum.io.threads%3D128%3Bqueued.max.requests%3D500/]
>  # Number of TopicPartition : 50~2000
>  # Size of Single Message : 1024B
>  
>  *_2.Config of KafkaProducer_* 
> ||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
> |lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|
> *_3.The best result of performance testing_*  
> ||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
> production||
> |550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|
> *_4.Phenomenon and  my doubt_*
>     _The upper limit of CPU usage has been reached  But  it does not 
> reach the upper limit of the bandwidth of the server  network. *We are 
> doubtful about which  cost too much CPU time and we want to Improve  
> performance and reduces CPU usage of Kafka server.*_
>   
>  _*5.Analysis*_
>         We analysis the JFIR of Kafka server when doing performance testing 
> .We found the hot spot method is 
> *_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
> *_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
>   we checking thread stack information we  also have found most CPU being 
> occupied by lots of thread  which  is busy decompressing messages.Then we 
> read source code of Kafka .
>        There is double-layer nested Iterator  when LogValidator do validate 
> every record.And There is a decompression for each message when traversing 
> every RecordBatch iterator. It is consuming CPU and affect total performance 
> that  decompress message._*The purpose of decompressing every messages just 
> for gain total size in bytes of one record and size in bytes of record body 
> when magic value to use is above 1 and no format conversion or value 
> overwriting is required for compressed messages.It is negative for 
> performance in common usage scenarios .*_{color:#33}Therefore, we suggest 
> that *_removing unnecessary decompression operation_* when doing  validation 
> for compressed message  when magic value to use is above 1 and no format 
> conversion or value overwriting is required for compressed messages.{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[Flower.min (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794193#comment-16794193
 ] 

Flower.min commented on KAFKA-8106:
---

I and My team modify some code of Kafka  and I need permission to commit Code. 
We do performance testing again with package include of modified code .the 
result of perfoemance testing is shown as below.The performance of production 
improved by 40%~50%,and resource usage of CPU reduced by 30%~50%.

> Remove unnecessary decompression operation when logValidator  do validation.
> 
>
> Key: KAFKA-8106
> URL: https://issues.apache.org/jira/browse/KAFKA-8106
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.1.1
> Environment: Server : 
> cpu:2*16 ; 
> MemTotal : 256G;
> Ethernet controller:Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network 
> Connection ; 
> SSD.
>Reporter: Flower.min
>Priority: Major
>  Labels: performance
>
>       We do performance testing about Kafka in specific scenarios as 
> described below .We build a kafka cluster with one broker,and create topics 
> with different number of partitions.Then we start lots of producer processes 
> to send large amounts of messages to one of the topics at one  testing .
> *_Specific Scenario_*
>   
>  *_1.Main config of Kafka_*  
>  # Main config of Kafka  
> server:[num.network.threads=6;num.io.threads=128;queued.max.requests=500|http://num.network.threads%3D6%3Bnum.io.threads%3D128%3Bqueued.max.requests%3D500/]
>  # Number of TopicPartition : 50~2000
>  # Size of Single Message : 1024B
>  
>  *_2.Config of KafkaProducer_* 
> ||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
> |lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|
> *_3.The best result of performance testing_*  
> ||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
> production||
> |550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|
> *_4.Phenomenon and  my doubt_*
>     _The upper limit of CPU usage has been reached  But  it does not 
> reach the upper limit of the bandwidth of the server  network. *We are 
> doubtful about which  cost too much CPU time and we want to Improve  
> performance and reduces CPU usage of Kafka server.*_
>   
>  _*5.Analysis*_
>         We analysis the JFIR of Kafka server when doing performance testing 
> .We found the hot spot method is 
> *_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
> *_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
>   we checking thread stack information we  also have found most CPU being 
> occupied by lots of thread  which  is busy decompressing messages.Then we 
> read source code of Kafka .
>        There is double-layer nested Iterator  when LogValidator do validate 
> every record.And There is a decompression for each message when traversing 
> every RecordBatch iterator. It is consuming CPU and affect total performance 
> that  decompress message._*The purpose of decompressing every messages just 
> for gain total size in bytes of one record and size in bytes of record body 
> when magic value to use is above 1 and no format conversion or value 
> overwriting is required for compressed messages.It is negative for 
> performance in common usage scenarios .*_{color:#33}Therefore, we suggest 
> that *_removing unnecessary decompression operation_* when doing  validation 
> for compressed message  when magic value to use is above 1 and no format 
> conversion or value overwriting is required for compressed messages.{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (KAFKA-8044) System Test Failure: ReassignPartitionsTest.test_reassign_partitions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794182#comment-16794182
 ] 

ASF GitHub Bot commented on KAFKA-8044:
---

omkreddy commented on pull request #6389: KAFKA-8044: Increase stop timeout for 
VerifiableProducer in ReassignPartitionsTest
URL: https://github.com/apache/kafka/pull/6389
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> System Test Failure: ReassignPartitionsTest.test_reassign_partitions
> 
>
> Key: KAFKA-8044
> URL: https://issues.apache.org/jira/browse/KAFKA-8044
> Project: Kafka
>  Issue Type: Bug
>  Components: system tests
>Affects Versions: 2.1.0
>Reporter: Manikumar
>Assignee: Manikumar
>Priority: Major
>
> {quote}
> Node ubuntu@worker10: did not stop within the specified timeout of 150 
> seconds Traceback (most recent call last): File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/tests/runner_client.py",
>  line 132, in run data = self.run_test() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/tests/runner_client.py",
>  line 189, in run_test return self.test_context.function(self.test) File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/mark/_mark.py",
>  line 428, in wrapper return functools.partial(f, *args, **kwargs)(*w_args, 
> **w_kwargs) File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/tests/kafkatest/tests/core/reassign_partitions_test.py",
>  line 148, in test_reassign_partitions self.move_start_offset() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/tests/kafkatest/tests/core/reassign_partitions_test.py",
>  line 121, in move_start_offset producer.stop() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/services/background_thread.py",
>  line 82, in stop super(BackgroundThreadService, self).stop() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/services/service.py",
>  line 279, in stop self.stop_node(node) File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/tests/kafkatest/services/verifiable_producer.py",
>  line 285, in stop_node (str(node.account), str(self.stop_timeout_sec)) 
> AssertionError: Node ubuntu@worker10: did not stop within the specified 
> timeout of 150 seconds
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (KAFKA-8044) System Test Failure: ReassignPartitionsTest.test_reassign_partitions

[Manikumar (JIRA)]

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

Manikumar resolved KAFKA-8044.
--
Resolution: Fixed

This was fixed in KAFKA-8061. Closing this issue for now. Will reopen the 
issue, If the issue occurs again.

> System Test Failure: ReassignPartitionsTest.test_reassign_partitions
> 
>
> Key: KAFKA-8044
> URL: https://issues.apache.org/jira/browse/KAFKA-8044
> Project: Kafka
>  Issue Type: Bug
>  Components: system tests
>Affects Versions: 2.1.0
>Reporter: Manikumar
>Assignee: Manikumar
>Priority: Major
>
> {quote}
> Node ubuntu@worker10: did not stop within the specified timeout of 150 
> seconds Traceback (most recent call last): File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/tests/runner_client.py",
>  line 132, in run data = self.run_test() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/tests/runner_client.py",
>  line 189, in run_test return self.test_context.function(self.test) File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/mark/_mark.py",
>  line 428, in wrapper return functools.partial(f, *args, **kwargs)(*w_args, 
> **w_kwargs) File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/tests/kafkatest/tests/core/reassign_partitions_test.py",
>  line 148, in test_reassign_partitions self.move_start_offset() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/tests/kafkatest/tests/core/reassign_partitions_test.py",
>  line 121, in move_start_offset producer.stop() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/services/background_thread.py",
>  line 82, in stop super(BackgroundThreadService, self).stop() File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/venv/lib/python2.7/site-packages/ducktape-0.7.5-py2.7.egg/ducktape/services/service.py",
>  line 279, in stop self.stop_node(node) File 
> "/home/jenkins/workspace/system-test-kafka_2.2-WCMO537TEDQFHHUF4SVK33SPUR5AG4KSITCCNJIYFPKDZQWBEJOA/kafka/tests/kafkatest/services/verifiable_producer.py",
>  line 285, in stop_node (str(node.account), str(self.stop_timeout_sec)) 
> AssertionError: Node ubuntu@worker10: did not stop within the specified 
> timeout of 150 seconds
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[Flower.min (JIRA)]

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

Flower.min updated KAFKA-8106:
--
Description: 
      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .

*_Specific Scenario_*
  
 *_1.Main config of Kafka_*  
 # Main config of Kafka  
server:[num.network.threads=6;num.io.threads=128;queued.max.requests=500|http://num.network.threads%3D6%3Bnum.io.threads%3D128%3Bqueued.max.requests%3D500/]
 # Number of TopicPartition : 50~2000
 # Size of Single Message : 1024B

 
 *_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|

*_3.The best result of performance testing_*  
||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
production||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|

*_4.Phenomenon and  my doubt_*
    _The upper limit of CPU usage has been reached  But  it does not reach 
the upper limit of the bandwidth of the server  network. *We are doubtful about 
which  cost too much CPU time and we want to Improve  performance and reduces 
CPU usage of Kafka server.*_
  
 _*5.Analysis*_
        We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
       There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.It is negative for performance in common usage 
scenarios .*_{color:#33}Therefore, we suggest that *_removing unnecessary 
decompression operation_* when doing  validation for compressed message  when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.{color}

  was:
h1. *Introduction of Performance Testing*

      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
 *_Specific Scenario_*
  
 *_1.Main config of Kafka_*  
 # Main config of Kafka  
server:[num.network.threads=6;num.io.threads=128;queued.max.requests=500|http://num.network.threads%3D6%3Bnum.io.threads%3D128%3Bqueued.max.requests%3D500/]
 # Number of TopicPartition : 50~2000
 # Size of Single Message : 1024B

 
 *_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|

*_3.The best result of performance testing_*  
||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
production||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|

*_4.Phenomenon and  my doubt_*
    _The upper limit of CPU usage has been reached  But  it does not reach 
the upper limit of the bandwidth of the server  network. *We are doubtful about 
which  cost too much CPU time and we want to Improve  performance and reduces 
CPU usage of Kafka server.*_
  
 _*5.Analysis*_
        We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
       There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value 

[jira] [Updated] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[Flower.min (JIRA)]

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

Flower.min updated KAFKA-8106:
--
Description: 
h1. *Introduction of Performance Testing*

      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
 *_Specific Scenario_*
  
 *_1.Main config of Kafka_*  
 # Main config of Kafka  
server:[num.network.threads=6;num.io.threads=128;queued.max.requests=500|http://num.network.threads%3D6%3Bnum.io.threads%3D128%3Bqueued.max.requests%3D500/]
 # Number of TopicPartition : 50~2000
 # Size of Single Message : 1024B

 
 *_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|

*_3.The best result of performance testing_*  
||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
production||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|

*_4.Phenomenon and  my doubt_*
    _The upper limit of CPU usage has been reached  But  it does not reach 
the upper limit of the bandwidth of the server  network. *We are doubtful about 
which  cost too much CPU time and we want to Improve  performance and reduces 
CPU usage of Kafka server.*_
  
 _*5.Analysis*_
        We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
       There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.It is negative for performance in common usage 
scenarios .*_{color:#33}Therefore, we suggest that *_removing unnecessary 
decompression operation_* when doing  validation for compressed message  when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.{color}

  was:
h1. *Introduction of Performance Testing*

      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
 *_Specific Scenario_*
  
 *_1.Main config of Kafka_*  
 # 
Main config of Kafka  
server:[num.network.threads=6;num.io.threads=128;queued.max.requests=500|http://num.network.threads%3D6%3Bnum.io.threads%3D128%3Bqueued.max.requests%3D500/]
 # 
Number of TopicPartition : 50~2000
 # 
Size of Single Message : 1024B

 
*_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|

*_3.The best result of performance testing_*  
||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
production||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|

*_4.Phenomenon and  my doubt_*
    _The upper limit of CPU usage has been reached  But  it does not reach 
the upper limit of the bandwidth of the server  network. *We are doubtful about 
which  cost too much CPU time and we want to Improve  performance and reduces 
CPU usage of Kafka server.*_
  
 _*5.Analysis*_
        We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
       There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use 

[jira] [Updated] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[Flower.min (JIRA)]

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

Flower.min updated KAFKA-8106:
--
Description: 
h1. *Introduction of Performance Testing*

      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
 *_Specific Scenario_*
  
 *_1.Main config of Kafka_*  
 # 
Main config of Kafka  
server:[num.network.threads=6;num.io.threads=128;queued.max.requests=500|http://num.network.threads%3D6%3Bnum.io.threads%3D128%3Bqueued.max.requests%3D500/]
 # 
Number of TopicPartition : 50~2000
 # 
Size of Single Message : 1024B

 
*_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|

*_3.The best result of performance testing_*  
||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
production||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|

*_4.Phenomenon and  my doubt_*
    _The upper limit of CPU usage has been reached  But  it does not reach 
the upper limit of the bandwidth of the server  network. *We are doubtful about 
which  cost too much CPU time and we want to Improve  performance and reduces 
CPU usage of Kafka server.*_
  
 _*5.Analysis*_
        We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
       There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.It is negative for performance in common usage 
scenarios .*_{color:#33}Therefore, we suggest that *_removing unnecessary 
decompression operation_* when doing  validation for compressed message  when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.{color}

  was:
h1. *Introduction of Performance Testing*

      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
 *_Specific Scenario_*
  
 *_1.Main config of Kafka_*  
||server:num.network.threads||server:num.io.threads||server:queued.max.requests||Number
 of TopicPartition||Size of Single Message||
|6|128|500|50~2000|1024B|

*_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|

*_3.The best result of performance testing_* 

 
||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
production||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|

*_4.Phenomenon and  my doubt_*
    _The upper limit of CPU usage has been reached  But  it does not reach 
the upper limit of the bandwidth of the server  network. *We are doubtful about 
which  cost too much CPU time and we want to Improve  performance and reduces 
CPU usage of Kafka server.*_
  
 _*5.Analysis*_
        We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
       There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.It 

[jira] [Updated] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[Flower.min (JIRA)]

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

Flower.min updated KAFKA-8106:
--
Description: 
h1. *Introduction of Performance Testing*

      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
 *_Specific Scenario_*
  
 *_1.Main config of Kafka_*  
||server:num.network.threads||server:num.io.threads||server:queued.max.requests||Number
 of TopicPartition||Size of Single Message||
|6|128|500|50~2000|1024B|

*_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|

*_3.The best result of performance testing_* 

 
||Network inflow rate||CPU Used (%)||Disk write speed||Performance of 
production||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |23,000,000 messages/s|

*_4.Phenomenon and  my doubt_*
    _The upper limit of CPU usage has been reached  But  it does not reach 
the upper limit of the bandwidth of the server  network. *We are doubtful about 
which  cost too much CPU time and we want to Improve  performance and reduces 
CPU usage of Kafka server.*_
  
 _*5.Analysis*_
        We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
       There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.It is negative for performance in common usage 
scenarios .*_{color:#33}Therefore, we suggest that *_removing unnecessary 
decompression operation_* when doing  validation for compressed message  when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.{color}

  was:
h1. *Introduction of Performance Testing*
      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
*_Specific Scenario_*
 
*_1.Main config of Kafka_*  
||server:num.network.threads||server:num.io.threads||server:queued.max.requests||Number
 of TopicPartition||Size of Single Message||
|6|128|500|50~2000|1024B|
 
*_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|
 
*_3.The best result of performance testing_* # 
_*Performance*_:23,000,000 messages/s.
 # 
_*Resource usage*_: 

||Network inflow rate||CPU(%)||Disk write speed||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |
*_4.Phenomenon and  my doubt_*
   __   The upper limit of CPU usage has been reached  But  it does not 
reach the upper limit of the bandwidth of the server  network. _*We are 
doubtful about which  cost too much CPU time and we want to Improve  
performance and reduces CPU usage of Kafka server.*_
 
_*5.Analysis*_
       We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
      There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.It is negative for performance in common usage 
scenarios .*_
h1. *Suggestion and Modifing 

[jira] [Updated] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[Flower.min (JIRA)]

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

Flower.min updated KAFKA-8106:
--
Environment: 
Server : 
cpu:2*16 ; 
MemTotal : 256G;
Ethernet controller:Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network 
Connection ; 
SSD.
 Labels: performance  (was: )
Description: 
h1. *Introduction of Performance Testing*
      We do performance testing about Kafka in specific scenarios as described 
below .We build a kafka cluster with one broker,and create topics with 
different number of partitions.Then we start lots of producer processes to send 
large amounts of messages to one of the topics at one  testing .
*_Specific Scenario_*
 
*_1.Main config of Kafka_*  
||server:num.network.threads||server:num.io.threads||server:queued.max.requests||Number
 of TopicPartition||Size of Single Message||
|6|128|500|50~2000|1024B|
 
*_2.Config of KafkaProducer_* 
||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
|lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|
 
*_3.The best result of performance testing_* # 
_*Performance*_:23,000,000 messages/s.
 # 
_*Resource usage*_: 

||Network inflow rate||CPU(%)||Disk write speed||
|550MB/s~610MB/s|97%～99%|:550MB/s~610MB/s       |
*_4.Phenomenon and  my doubt_*
   __   The upper limit of CPU usage has been reached  But  it does not 
reach the upper limit of the bandwidth of the server  network. _*We are 
doubtful about which  cost too much CPU time and we want to Improve  
performance and reduces CPU usage of Kafka server.*_
 
_*5.Analysis*_
       We analysis the JFIR of Kafka server when doing performance testing .We 
found the hot spot method is 
*_"java.io.DataInputStream.readFully(byte[],int,int)"_* and 
*_"org.apache.kafka.common.record.KafkaLZ4BlockInputStream.read(byte[],int,int)"_*.When
  we checking thread stack information we  also have found most CPU being 
occupied by lots of thread  which  is busy decompressing messages.Then we read 
source code of Kafka .
      There is double-layer nested Iterator  when LogValidator do validate 
every record.And There is a decompression for each message when traversing 
every RecordBatch iterator. It is consuming CPU and affect total performance 
that  decompress message._*The purpose of decompressing every messages just for 
gain total size in bytes of one record and size in bytes of record body when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages.It is negative for performance in common usage 
scenarios .*_
h1. *Suggestion and Modifing Code*

{color:#33}     Therefore, we suggest that *_removing unnecessary 
decompression operation_* when doing  validation for compressed message  when 
magic value to use is above 1 and no format conversion or value overwriting is 
required for compressed messages{color}
h1. *Performance Testing Again*

     **     We do performance testing again with package include of modified 
code .the result of perfoemance testing is shown as below.*_The performance of 
production improved by 40%~50%,and resource usage of CPU reduced by 30%~50%._*
 # 
*_Performance of production_* :32,000,000 messages/s.
 # *_Resource usage_*: 
||Network inflow rate||CPU(%)||Disk write speed||
|800M/s~1GB/s|10%～40%|800M/s~1GB/s         |

 
Summary: Remove unnecessary decompression operation when logValidator  
do validation.  (was: Remove )

> Remove unnecessary decompression operation when logValidator  do validation.
> 
>
> Key: KAFKA-8106
> URL: https://issues.apache.org/jira/browse/KAFKA-8106
> Project: Kafka
>  Issue Type: Bug
>  Components: clients, core
>Affects Versions: 2.1.1
> Environment: Server : 
> cpu:2*16 ; 
> MemTotal : 256G;
> Ethernet controller:Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network 
> Connection ; 
> SSD.
>Reporter: Flower.min
>Priority: Major
>  Labels: performance
>
> h1. *Introduction of Performance Testing*
>       We do performance testing about Kafka in specific scenarios as 
> described below .We build a kafka cluster with one broker,and create topics 
> with different number of partitions.Then we start lots of producer processes 
> to send large amounts of messages to one of the topics at one  testing .
> *_Specific Scenario_*
>  
> *_1.Main config of Kafka_*  
> ||server:num.network.threads||server:num.io.threads||server:queued.max.requests||Number
>  of TopicPartition||Size of Single Message||
> |6|128|500|50~2000|1024B|
>  
> *_2.Config of KafkaProducer_* 
> ||compression.type||[linger.ms|http://linger.ms/]||batch.size||buffer.memory||
> |lz4|1000ms~5000ms|16KB/10KB/100KB|128MB|
>  
> *_3.The best result of performance testing_* # 
> _*Performance*_:23,000,000 messages/s.

[jira] [Commented] (KAFKA-7898) ERROR Caught unexpected throwable (org.apache.zookeeper.ClientCnxn)

[Manikumar (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794176#comment-16794176
 ] 

Manikumar commented on KAFKA-7898:
--

[~steven-usabilla] I think it is good to have fix in 2.1 branch as well. Would 
like to submit a PR to fix it?

> ERROR Caught unexpected throwable (org.apache.zookeeper.ClientCnxn)
> ---
>
> Key: KAFKA-7898
> URL: https://issues.apache.org/jira/browse/KAFKA-7898
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Gabriel Lukacs
>Priority: Major
>
> We observed a NullPointerException on one of our broker in 3 broker cluster 
> environment. If I list the processes and open ports it seems that the faulty 
> broker is running, but the kafka-connect (we used it also) periodically 
> restarts due to fact that it can not connect to the kafka cluster (configured 
> ssl & plaintext mode too). Is it a bug in kafka/zookeeper?
>  
> [2019-02-05 14:28:11,359] WARN Client session timed out, have not heard from 
> server in 4141ms for sessionid 0x310166e 
> (org.apache.zookeeper.ClientCnxn)
> [2019-02-05 14:28:12,525] ERROR Caught unexpected throwable 
> (org.apache.zookeeper.ClientCnxn)
> java.lang.NullPointerException
>  at 
> kafka.zookeeper.ZooKeeperClient$$anon$8.processResult(ZooKeeperClient.scala:217)
>  at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:633)
>  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:508)
> [2019-02-05 14:28:12,526] ERROR Caught unexpected throwable 
> (org.apache.zookeeper.ClientCnxn)
> [2019-02-05 14:28:22,701] WARN Client session timed out, have not heard from 
> server in 4004ms for sessionid 0x310166e 
> (org.apache.zookeeper.ClientCnxn)
> [2019-02-05 14:28:28,670] WARN Client session timed out, have not heard from 
> server in 4049ms for sessionid 0x310166e 
> (org.apache.zookeeper.ClientCnxn)
> [2019-02-05 15:05:20,601] WARN [GroupCoordinator 1]: Failed to write empty 
> metadata for group 
> encodable-emvTokenAccess-delta-encoder-group-emvIssuerAccess-v2-2-0: The 
> group is rebalancing, so a rejoin is needed. 
> (kafka.coordinator.group.GroupCoordinator)
> kafka 7381 1 0 14:22 ? 00:00:19 java -Xmx512M -Xms512M -server -XX:+UseG1GC 
> -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 
> -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true 
> -Xloggc:/opt/kafka/bin/../logs/zookeeper-gc.log -verbose:gc 
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps 
> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M 
> -Dcom.sun.management.jmxremote 
> -Dcom.sun.management.jmxremote.authenticate=false 
> -Dcom.sun.management.jmxremote.ssl=false 
> -Dkafka.logs.dir=/opt/kafka/bin/../logs 
> -Dlog4j.configuration=file:/opt/kafka/config/zoo-log4j.properties -cp 
> 

[jira] [Commented] (KAFKA-8114) Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoGroupAcl

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794163#comment-16794163
 ] 

ASF GitHub Bot commented on KAFKA-8114:
---

omkreddy commented on pull request #6452: KAFKA-8114: Wait for SCRAM credential 
propagation in DelegationTokenEdToEndAuthorizationTest
URL: https://github.com/apache/kafka/pull/6452
 
 
   
   
   ### Committer Checklist (excluded from commit message)
   - [ ] Verify design and implementation 
   - [ ] Verify test coverage and CI build status
   - [ ] Verify documentation (including upgrade notes)
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Flaky Test DelegationTokenEndToEndAuthorizationTest#testNoGroupAcl
> --
>
> Key: KAFKA-8114
> URL: https://issues.apache.org/jira/browse/KAFKA-8114
> Project: Kafka
>  Issue Type: Bug
>  Components: core, unit tests
>Affects Versions: 2.3.0
>Reporter: Matthias J. Sax
>Priority: Critical
>  Labels: flaky-test
> Fix For: 2.3.0
>
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/3254/testReport/junit/kafka.api/DelegationTokenEndToEndAuthorizationTest/testNoGroupAcl/]
> {quote}java.util.concurrent.ExecutionException: 
> org.apache.kafka.common.errors.SaslAuthenticationException: Authentication 
> failed during authentication due to invalid credentials with SASL mechanism 
> SCRAM-SHA-256 at 
> org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
>  at 
> org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.createDelegationToken(DelegationTokenEndToEndAuthorizationTest.scala:88)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.configureSecurityAfterServersStart(DelegationTokenEndToEndAuthorizationTest.scala:63)
>  at 
> kafka.integration.KafkaServerTestHarness.setUp(KafkaServerTestHarness.scala:107)
>  at kafka.api.IntegrationTestHarness.doSetup(IntegrationTestHarness.scala:81) 
> at kafka.api.IntegrationTestHarness.setUp(IntegrationTestHarness.scala:73) at 
> kafka.api.EndToEndAuthorizationTest.setUp(EndToEndAuthorizationTest.scala:183)
>  at 
> kafka.api.DelegationTokenEndToEndAuthorizationTest.setUp(DelegationTokenEndToEndAuthorizationTest.scala:74){quote}
> STDOUT
> {quote}Adding ACLs for resource `Cluster:LITERAL:kafka-cluster`: 
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: * Current ACLs for resource `Cluster:LITERAL:kafka-cluster`: 
> User:scram-admin has Allow permission for operations: ClusterAction from 
> hosts: * Adding ACLs for resource `Topic:LITERAL:*`: User:scram-admin has 
> Allow permission for operations: Read from hosts: * Current ACLs for resource 
> `Topic:LITERAL:*`: User:scram-admin has Allow permission for operations: Read 
> from hosts: * Completed Updating config for entity: user-principal 
> 'scram-admin'. Completed Updating config for entity: user-principal 
> 'scram-user'. Adding ACLs for resource `Topic:LITERAL:e2etopic`: 
> User:scram-user has Allow permission for operations: Write from hosts: * 
> User:scram-user has Allow permission for operations: Create from hosts: * 
> User:scram-user has Allow permission for operations: Describe from hosts: * 
> Current ACLs for resource `Topic:LITERAL:e2etopic`: User:scram-user has Allow 
> permission for operations: Write from hosts: * User:scram-user has Allow 
> permission for operations: Create from hosts: * User:scram-user has Allow 
> permission for operations: Describe from hosts: * Adding ACLs for resource 
> `Group:LITERAL:group`: User:scram-user has Allow permission for operations: 
> Read from hosts: * Current ACLs for resource `Group:LITERAL:group`: 
> User:scram-user has Allow permission for operations: Read from hosts: * 
> Current ACLs for resource `Topic:LITERAL:e2etopic`: User:scram-user has Allow 
> permission for operations: Write from hosts: * User:scram-user has Allow 
> permission for operations: Create from hosts: * Current ACLs for resource 
> `Topic:LITERAL:e2etopic`: User:scram-user has Allow permission for 
> operations: Create from hosts: * [2019-03-15 09:58:16,481] ERROR [Consumer 
> clientId=consumer-99, groupId=group] Topic authorization failed for topics 
> [e2etopic] (org.apache.kafka.clients.Metadata:297)