[jira] [Commented] (KAFKA-8345) Create an Administrative API for Replica Reassignment
[ https://issues.apache.org/jira/browse/KAFKA-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927262#comment-16927262 ] ASF GitHub Bot commented on KAFKA-8345: --- cmccabe commented on pull request #7128: KAFKA-8345 (KIP-455): Controller and KafkaApi changes (part 3/4) URL: https://github.com/apache/kafka/pull/7128 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 > Create an Administrative API for Replica Reassignment > - > > Key: KAFKA-8345 > URL: https://issues.apache.org/jira/browse/KAFKA-8345 > Project: Kafka > Issue Type: Improvement >Reporter: Colin P. McCabe >Assignee: Colin P. McCabe >Priority: Major > > Create an Administrative API for Replica Reassignment, as discussed in KIP-455 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (KAFKA-8552) Use SASL authentication in ConfigCommand for connection to zookeeper
[
https://issues.apache.org/jira/browse/KAFKA-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927233#comment-16927233
]
Liu edited comment on KAFKA-8552 at 9/11/19 4:44 AM:
-
I've been working on this recently, and I have an idea. Under the Scram
mechanism, I mainly want to control other people add users and add permissions,
so I will be in the /config/users and /kafka-acl under the two paths add
digest authentication, part of the Java code is as follows:
kafkaZkClient.currentZooKeeper().addAuthInfo("digest", "bog:bog".getBytes());
AdminZkClient adminZkClient = new AdminZkClient(kafkaZkClient);
adminZkClient.changeConfigs(ConfigType.User(), name, configPro);
was (Author: boge):
I've been working on this recently, and I have an idea. Under the Scram
mechanism, I mainly want to control other people add users and add permissions,
so I will be in the/config/users/kafka - and acl under the two paths and digest
authentication, part of the Java code is as follows:
kafkaZkClient.currentZooKeeper().addAuthInfo("digest", "bog:bog".getBytes());
AdminZkClient adminZkClient = new AdminZkClient(kafkaZkClient);
adminZkClient.changeConfigs(ConfigType.User(), name, configPro);
> Use SASL authentication in ConfigCommand for connection to zookeeper
>
>
> Key: KAFKA-8552
> URL: https://issues.apache.org/jira/browse/KAFKA-8552
> Project: Kafka
> Issue Type: Improvement
> Components: zkclient
>Affects Versions: 2.2.1
>Reporter: Tim Lansbergen
>Priority: Minor
> Attachments: image (1).png, image.png
>
>
> Currently we are using the kafka-configs script to create SCRAM users in
> zookeeper. I execute the following command on the machine:
> *./kafka-configs --zookeeper _ip-adres_:2181 --alter --add-config
> 'SCRAM-SHA-256=[password=password]' --entity-type users --entity-name user123*
> I would like to create users dynamically via a Java api. Since it is not
> possible to create SCRAM users via the KafkaAdminApi (please confirm?), I am
> now using the Kafka Scala class 'AdminZkClient' to create users the same as
> way as the ConfigCommand currently does. It looks like the AdminZkClient
> doesn't provide a way to authenticate against zookeeper using SASL. I'm
> currently connecting to zookeeper without authentication and this is a
> security issue. Is it possible to connect with the AdminZkClient with SASL
> authentication?
> I'm aware of issue KAFKA-5722 which is an improvement to use the AdminClient
> in the ConfigCommand class so this issue might be a duplicate but I would
> like to know if it is possible to authenticate using SASL with the
> AdminZkClient.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-8552) Use SASL authentication in ConfigCommand for connection to zookeeper
[
https://issues.apache.org/jira/browse/KAFKA-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927246#comment-16927246
]
Liu commented on KAFKA-8552:
I have encountered some problems in launching Zookeeper sasl certification. I
wonder if you have any good Suggestions. When I launch the Zookeeper server，I
have configured
“-Djava.security.auth.login.config=/data/boge/kafka/config/zookeeper-jaas.conf”，The
contents of zookeeper-jaas.conf are as follows:
{code:java}
Server {
org.apache.zookeeper.server.auth.DigestLoginModule required
user_super="adminsecret"
user_zooclient="zooclientpwd";
};{code}
zookeeper.properties
{code:java}
authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
{code}
kafka kafka-broker-jaas.conf
{code:java}
Client {
org.apache.kafka.common.security.plain.PlainLoginModule required
username="zooclient"
password="zooclientpwd";
};
{code}
kafka server.propertie
{code:java}
zookeeper.set.acl=true
{code}
In this way, I have implemented the connection of Zookeeper with
authentication.It also allows the brokers to set SASL ACL on zookeeper nodes
which locks these nodes down so that only the brokers can modify it.
!image.png!!image (1).png!
However, in some scenarios, my kafka may fail to be started. For example, if I
return from a version with Zookeeper sasl authentication to a version without
sasl authentication, the data loaded by Zookeeper is still encrypted. In this
case, kafka cannot connect to Zookeeper because of Client configuration, and
the startup fails.
I hope you can understand what I'm talking about and give me some suggestions.
thanks!
> Use SASL authentication in ConfigCommand for connection to zookeeper
>
>
> Key: KAFKA-8552
> URL: https://issues.apache.org/jira/browse/KAFKA-8552
> Project: Kafka
> Issue Type: Improvement
> Components: zkclient
>Affects Versions: 2.2.1
>Reporter: Tim Lansbergen
>Priority: Minor
> Attachments: image (1).png, image.png
>
>
> Currently we are using the kafka-configs script to create SCRAM users in
> zookeeper. I execute the following command on the machine:
> *./kafka-configs --zookeeper _ip-adres_:2181 --alter --add-config
> 'SCRAM-SHA-256=[password=password]' --entity-type users --entity-name user123*
> I would like to create users dynamically via a Java api. Since it is not
> possible to create SCRAM users via the KafkaAdminApi (please confirm?), I am
> now using the Kafka Scala class 'AdminZkClient' to create users the same as
> way as the ConfigCommand currently does. It looks like the AdminZkClient
> doesn't provide a way to authenticate against zookeeper using SASL. I'm
> currently connecting to zookeeper without authentication and this is a
> security issue. Is it possible to connect with the AdminZkClient with SASL
> authentication?
> I'm aware of issue KAFKA-5722 which is an improvement to use the AdminClient
> in the ConfigCommand class so this issue might be a duplicate but I would
> like to know if it is possible to authenticate using SASL with the
> AdminZkClient.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (KAFKA-8552) Use SASL authentication in ConfigCommand for connection to zookeeper
[ https://issues.apache.org/jira/browse/KAFKA-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu updated KAFKA-8552: --- Attachment: image (1).png > Use SASL authentication in ConfigCommand for connection to zookeeper > > > Key: KAFKA-8552 > URL: https://issues.apache.org/jira/browse/KAFKA-8552 > Project: Kafka > Issue Type: Improvement > Components: zkclient >Affects Versions: 2.2.1 >Reporter: Tim Lansbergen >Priority: Minor > Attachments: image (1).png, image.png > > > Currently we are using the kafka-configs script to create SCRAM users in > zookeeper. I execute the following command on the machine: > *./kafka-configs --zookeeper _ip-adres_:2181 --alter --add-config > 'SCRAM-SHA-256=[password=password]' --entity-type users --entity-name user123* > I would like to create users dynamically via a Java api. Since it is not > possible to create SCRAM users via the KafkaAdminApi (please confirm?), I am > now using the Kafka Scala class 'AdminZkClient' to create users the same as > way as the ConfigCommand currently does. It looks like the AdminZkClient > doesn't provide a way to authenticate against zookeeper using SASL. I'm > currently connecting to zookeeper without authentication and this is a > security issue. Is it possible to connect with the AdminZkClient with SASL > authentication? > I'm aware of issue KAFKA-5722 which is an improvement to use the AdminClient > in the ConfigCommand class so this issue might be a duplicate but I would > like to know if it is possible to authenticate using SASL with the > AdminZkClient. > Thanks! > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8552) Use SASL authentication in ConfigCommand for connection to zookeeper
[ https://issues.apache.org/jira/browse/KAFKA-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu updated KAFKA-8552: --- Attachment: image.png > Use SASL authentication in ConfigCommand for connection to zookeeper > > > Key: KAFKA-8552 > URL: https://issues.apache.org/jira/browse/KAFKA-8552 > Project: Kafka > Issue Type: Improvement > Components: zkclient >Affects Versions: 2.2.1 >Reporter: Tim Lansbergen >Priority: Minor > Attachments: image.png > > > Currently we are using the kafka-configs script to create SCRAM users in > zookeeper. I execute the following command on the machine: > *./kafka-configs --zookeeper _ip-adres_:2181 --alter --add-config > 'SCRAM-SHA-256=[password=password]' --entity-type users --entity-name user123* > I would like to create users dynamically via a Java api. Since it is not > possible to create SCRAM users via the KafkaAdminApi (please confirm?), I am > now using the Kafka Scala class 'AdminZkClient' to create users the same as > way as the ConfigCommand currently does. It looks like the AdminZkClient > doesn't provide a way to authenticate against zookeeper using SASL. I'm > currently connecting to zookeeper without authentication and this is a > security issue. Is it possible to connect with the AdminZkClient with SASL > authentication? > I'm aware of issue KAFKA-5722 which is an improvement to use the AdminClient > in the ConfigCommand class so this issue might be a duplicate but I would > like to know if it is possible to authenticate using SASL with the > AdminZkClient. > Thanks! > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (KAFKA-8552) Use SASL authentication in ConfigCommand for connection to zookeeper
[
https://issues.apache.org/jira/browse/KAFKA-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927233#comment-16927233
]
Liu commented on KAFKA-8552:
I've been working on this recently, and I have an idea. Under the Scram
mechanism, I mainly want to control other people add users and add permissions,
so I will be in the/config/users/kafka - and acl under the two paths and digest
authentication, part of the Java code is as follows:
kafkaZkClient.currentZooKeeper().addAuthInfo("digest", "bog:bog".getBytes());
AdminZkClient adminZkClient = new AdminZkClient(kafkaZkClient);
adminZkClient.changeConfigs(ConfigType.User(), name, configPro);
> Use SASL authentication in ConfigCommand for connection to zookeeper
>
>
> Key: KAFKA-8552
> URL: https://issues.apache.org/jira/browse/KAFKA-8552
> Project: Kafka
> Issue Type: Improvement
> Components: zkclient
>Affects Versions: 2.2.1
>Reporter: Tim Lansbergen
>Priority: Minor
>
> Currently we are using the kafka-configs script to create SCRAM users in
> zookeeper. I execute the following command on the machine:
> *./kafka-configs --zookeeper _ip-adres_:2181 --alter --add-config
> 'SCRAM-SHA-256=[password=password]' --entity-type users --entity-name user123*
> I would like to create users dynamically via a Java api. Since it is not
> possible to create SCRAM users via the KafkaAdminApi (please confirm?), I am
> now using the Kafka Scala class 'AdminZkClient' to create users the same as
> way as the ConfigCommand currently does. It looks like the AdminZkClient
> doesn't provide a way to authenticate against zookeeper using SASL. I'm
> currently connecting to zookeeper without authentication and this is a
> security issue. Is it possible to connect with the AdminZkClient with SASL
> authentication?
> I'm aware of issue KAFKA-5722 which is an improvement to use the AdminClient
> in the ConfigCommand class so this issue might be a duplicate but I would
> like to know if it is possible to authenticate using SASL with the
> AdminZkClient.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-8179) Incremental Rebalance Protocol for Kafka Consumer
[ https://issues.apache.org/jira/browse/KAFKA-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927200#comment-16927200 ] ASF GitHub Bot commented on KAFKA-8179: --- ableegoldman commented on pull request #7321: KAFKA-8179: minor, refactoring Streams for cooperative rebalancing URL: https://github.com/apache/kafka/pull/7321 Breaking up part 7 (KIP-429 for Streams) into multiple PRs, starting with some refactoring of the rebalancing related code. This PR does NOT allow cooperative rebalancing in Streams, it just lays the groundwork for it. 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 > Incremental Rebalance Protocol for Kafka Consumer > - > > Key: KAFKA-8179 > URL: https://issues.apache.org/jira/browse/KAFKA-8179 > Project: Kafka > Issue Type: Improvement > Components: consumer >Reporter: Guozhang Wang >Assignee: Guozhang Wang >Priority: Major > > Recently Kafka community is promoting cooperative rebalancing to mitigate the > pain points in the stop-the-world rebalancing protocol. This ticket is > created to initiate that idea at the Kafka consumer client, which will be > beneficial for heavy-stateful consumers such as Kafka Streams applications. > In short, the scope of this ticket includes reducing unnecessary rebalance > latency due to heavy partition migration: i.e. partitions being revoked and > re-assigned. This would make the built-in consumer assignors (range, > round-robin etc) to be aware of previously assigned partitions and be sticky > in best-effort. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (KAFKA-8817) Flaky Test KafkaProducerTest.testCloseIsForcedOnPendingAddOffsetRequest
[
https://issues.apache.org/jira/browse/KAFKA-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guozhang Wang resolved KAFKA-8817.
--
Fix Version/s: 2.4.0
Assignee: Guozhang Wang
Resolution: Fixed
> Flaky Test KafkaProducerTest.testCloseIsForcedOnPendingAddOffsetRequest
> ---
>
> Key: KAFKA-8817
> URL: https://issues.apache.org/jira/browse/KAFKA-8817
> Project: Kafka
> Issue Type: Bug
> Components: core
>Reporter: Chris Pettitt
>Assignee: Guozhang Wang
>Priority: Major
> Labels: flaky-test
> Fix For: 2.4.0
>
>
> Error:
> {code:java}
> org.junit.runners.model.TestTimedOutException: test timed out after 5000
> milliseconds
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1260)
> at
> org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:1190)
> at
> org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:1167)
> at
> org.apache.kafka.clients.producer.KafkaProducerTest.testCloseIsForcedOnPendingAddOffsetRequest(KafkaProducerTest.java:894)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:288)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:282)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Currently 100% reproducible locally when running the whole test suite. Does
> not repro when running this test class individually. This is on the latest
> upstream trunk with no changes applied.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-8817) Flaky Test KafkaProducerTest.testCloseIsForcedOnPendingAddOffsetRequest
[
https://issues.apache.org/jira/browse/KAFKA-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927190#comment-16927190
]
ASF GitHub Bot commented on KAFKA-8817:
---
guozhangwang commented on pull request #7313: KAFKA-8817: Remove timeout for
the whole test
URL: https://github.com/apache/kafka/pull/7313
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 KafkaProducerTest.testCloseIsForcedOnPendingAddOffsetRequest
> ---
>
> Key: KAFKA-8817
> URL: https://issues.apache.org/jira/browse/KAFKA-8817
> Project: Kafka
> Issue Type: Bug
> Components: core
>Reporter: Chris Pettitt
>Priority: Major
> Labels: flaky-test
>
> Error:
> {code:java}
> org.junit.runners.model.TestTimedOutException: test timed out after 5000
> milliseconds
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1260)
> at
> org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:1190)
> at
> org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:1167)
> at
> org.apache.kafka.clients.producer.KafkaProducerTest.testCloseIsForcedOnPendingAddOffsetRequest(KafkaProducerTest.java:894)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:288)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:282)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Currently 100% reproducible locally when running the whole test suite. Does
> not repro when running this test class individually. This is on the latest
> upstream trunk with no changes applied.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (KAFKA-8747) Flaky Test ControllerEventManagerTest#testEventQueueTime
[
https://issues.apache.org/jira/browse/KAFKA-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gustafson resolved KAFKA-8747.
Resolution: Fixed
> Flaky Test ControllerEventManagerTest#testEventQueueTime
>
>
> Key: KAFKA-8747
> URL: https://issues.apache.org/jira/browse/KAFKA-8747
> Project: Kafka
> Issue Type: Bug
> Components: core, unit tests
>Affects Versions: 2.4.0
>Reporter: Matthias J. Sax
>Assignee: Stanislav Kozlovski
>Priority: Critical
> Labels: flaky-test
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/6671/testReport/junit/kafka.controller/ControllerEventManagerTest/testEventQueueTime/]
> {quote}java.lang.AssertionError: expected:<500.0> but was:<0.0> at
> org.junit.Assert.fail(Assert.java:89) at
> org.junit.Assert.failNotEquals(Assert.java:835) at
> org.junit.Assert.assertEquals(Assert.java:555) at
> org.junit.Assert.assertEquals(Assert.java:685) at
> kafka.controller.ControllerEventManagerTest.testEventQueueTime(ControllerEventManagerTest.scala:100){quote}
> STDOUT:
> {quote}[2019-08-01 18:51:09,815] ERROR [ControllerEventThread controllerId=0]
> Uncaught error processing event BrokerChange
> (kafka.controller.ControllerEventManager$ControllerEventThread:76)
> java.lang.NullPointerException at
> kafka.controller.ControllerEventManagerTest.$anonfun$testEventThatThrowsException$1(ControllerEventManagerTest.scala:112)
> at scala.Function0.apply$mcV$sp(Function0.scala:39) at
> kafka.controller.ControllerEventManagerTest$$anon$3.process(ControllerEventManagerTest.scala:126)
> at kafka.controller.QueuedEvent.process(ControllerEventManager.scala:53) at
> kafka.controller.ControllerEventManager$ControllerEventThread.$anonfun$doWork$1(ControllerEventManager.scala:137)
> at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23) at
> kafka.metrics.KafkaTimer.time(KafkaTimer.scala:31) at
> kafka.controller.ControllerEventManager$ControllerEventThread.doWork(ControllerEventManager.scala:137)
> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:89)
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-8747) Flaky Test ControllerEventManagerTest#testEventQueueTime
[
https://issues.apache.org/jira/browse/KAFKA-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927142#comment-16927142
]
ASF GitHub Bot commented on KAFKA-8747:
---
hachikuji commented on pull request #7320: KAFKA-8747: Fix the flaky
ControllerEventManagerTest#testEventQueueTimeQuery test
URL: https://github.com/apache/kafka/pull/7320
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 ControllerEventManagerTest#testEventQueueTime
>
>
> Key: KAFKA-8747
> URL: https://issues.apache.org/jira/browse/KAFKA-8747
> Project: Kafka
> Issue Type: Bug
> Components: core, unit tests
>Affects Versions: 2.4.0
>Reporter: Matthias J. Sax
>Assignee: Stanislav Kozlovski
>Priority: Critical
> Labels: flaky-test
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/6671/testReport/junit/kafka.controller/ControllerEventManagerTest/testEventQueueTime/]
> {quote}java.lang.AssertionError: expected:<500.0> but was:<0.0> at
> org.junit.Assert.fail(Assert.java:89) at
> org.junit.Assert.failNotEquals(Assert.java:835) at
> org.junit.Assert.assertEquals(Assert.java:555) at
> org.junit.Assert.assertEquals(Assert.java:685) at
> kafka.controller.ControllerEventManagerTest.testEventQueueTime(ControllerEventManagerTest.scala:100){quote}
> STDOUT:
> {quote}[2019-08-01 18:51:09,815] ERROR [ControllerEventThread controllerId=0]
> Uncaught error processing event BrokerChange
> (kafka.controller.ControllerEventManager$ControllerEventThread:76)
> java.lang.NullPointerException at
> kafka.controller.ControllerEventManagerTest.$anonfun$testEventThatThrowsException$1(ControllerEventManagerTest.scala:112)
> at scala.Function0.apply$mcV$sp(Function0.scala:39) at
> kafka.controller.ControllerEventManagerTest$$anon$3.process(ControllerEventManagerTest.scala:126)
> at kafka.controller.QueuedEvent.process(ControllerEventManager.scala:53) at
> kafka.controller.ControllerEventManager$ControllerEventThread.$anonfun$doWork$1(ControllerEventManager.scala:137)
> at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23) at
> kafka.metrics.KafkaTimer.time(KafkaTimer.scala:31) at
> kafka.controller.ControllerEventManager$ControllerEventThread.doWork(ControllerEventManager.scala:137)
> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:89)
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (KAFKA-8222) Admin client changes to add ability to batch remove static members
[ https://issues.apache.org/jira/browse/KAFKA-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boyang Chen resolved KAFKA-8222. Resolution: Fixed > Admin client changes to add ability to batch remove static members > -- > > Key: KAFKA-8222 > URL: https://issues.apache.org/jira/browse/KAFKA-8222 > Project: Kafka > Issue Type: Sub-task > Components: consumer, streams >Reporter: Boyang Chen >Assignee: Boyang Chen >Priority: Major > > After leave group [changes|https://issues.apache.org/jira/browse/KAFKA-8221] > become effective, we need to add admin support to use it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (KAFKA-7018) persist memberId for consumer restart
[
https://issues.apache.org/jira/browse/KAFKA-7018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boyang Chen resolved KAFKA-7018.
Fix Version/s: 2.4.0
Resolution: Fixed
> persist memberId for consumer restart
> -
>
> Key: KAFKA-7018
> URL: https://issues.apache.org/jira/browse/KAFKA-7018
> Project: Kafka
> Issue Type: Improvement
> Components: consumer, streams
>Reporter: Boyang Chen
>Assignee: Boyang Chen
>Priority: Major
> Fix For: 2.4.0
>
>
> In group coordinator, there is a logic to neglect join group request from
> existing follower consumers:
> {code:java}
> case Empty | Stable =>
> if (memberId == JoinGroupRequest.UNKNOWN_MEMBER_ID) {
> // if the member id is unknown, register the member to the group
> addMemberAndRebalance(rebalanceTimeoutMs, sessionTimeoutMs, clientId,
> clientHost, protocolType, protocols, group, responseCallback)
> } else {
> val member = group.get(memberId)
> if (group.isLeader(memberId) || !member.matches(protocols)) {
> // force a rebalance if a member has changed metadata or if the leader
> sends JoinGroup.
> // The latter allows the leader to trigger rebalances for changes
> affecting assignment
> // which do not affect the member metadata (such as topic metadata
> changes for the consumer)
> updateMemberAndRebalance(group, member, protocols, responseCallback)
> } else {
> // for followers with no actual change to their metadata, just return
> group information
> // for the current generation which will allow them to issue SyncGroup
> responseCallback(JoinGroupResult(
> members = Map.empty,
> memberId = memberId,
> generationId = group.generationId,
> subProtocol = group.protocolOrNull,
> leaderId = group.leaderOrNull,
> error = Errors.NONE))
> }
> {code}
> While looking at the AbstractCoordinator, I found that the generation was
> hard-coded as
> NO_GENERATION on restart, which means we will send UNKNOWN_MEMBER_ID in the
> first join group request. This means we will treat the restarted consumer as
> a new member, so the rebalance will be triggered until session timeout.
> I'm trying to clarify the following things before we extend the discussion:
> # Whether my understanding of the above logic is right (Hope [~mjsax] could
> help me double check)
> # Whether it makes sense to persist last round of memberId for consumers? We
> currently only need this feature in stream application, but will do no harm
> if we also use it for consumer in general. This would be a nice-to-have
> feature on consumer restart when we configured the loading-previous-memberId
> to true. If we failed, simply use the UNKNOWN_MEMBER_ID
> # The behavior could also be changed on the broker side, but I suspect it is
> very risky. So far client side change should be the least effort. The end
> goal is to avoid excessive rebalance from the same consumer restart, so if
> you feel server side change could also help, we could further discuss.
> Thank you for helping out! [~mjsax] [~guozhang]
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (KAFKA-8896) NoSuchElementException after coordinator move
Jason Gustafson created KAFKA-8896:
--
Summary: NoSuchElementException after coordinator move
Key: KAFKA-8896
URL: https://issues.apache.org/jira/browse/KAFKA-8896
Project: Kafka
Issue Type: Bug
Reporter: Jason Gustafson
Assignee: Boyang Chen
Caught this exception in the wild:
{code:java}
java.util.NoSuchElementException: key not found:
consumer-group-38981ebe-4361-44e7-b710-7d11f5d35639
at scala.collection.MapLike.default(MapLike.scala:235)
at scala.collection.MapLike.default$(MapLike.scala:234)
at scala.collection.AbstractMap.default(Map.scala:63)
at scala.collection.mutable.HashMap.apply(HashMap.scala:69)
at kafka.coordinator.group.GroupMetadata.get(GroupMetadata.scala:214)
at
kafka.coordinator.group.GroupCoordinator.$anonfun$tryCompleteHeartbeat$1(GroupCoordinator.scala:1008)
at
scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:253)
at kafka.coordinator.group.GroupMetadata.inLock(GroupMetadata.scala:209)
at
kafka.coordinator.group.GroupCoordinator.tryCompleteHeartbeat(GroupCoordinator.scala:1001)
at
kafka.coordinator.group.DelayedHeartbeat.tryComplete(DelayedHeartbeat.scala:34)
at
kafka.server.DelayedOperation.maybeTryComplete(DelayedOperation.scala:122)
at
kafka.server.DelayedOperationPurgatory$Watchers.tryCompleteWatched(DelayedOperation.scala:391)
at
kafka.server.DelayedOperationPurgatory.checkAndComplete(DelayedOperation.scala:295)
at
kafka.coordinator.group.GroupCoordinator.completeAndScheduleNextExpiration(GroupCoordinator.scala:802)
at
kafka.coordinator.group.GroupCoordinator.completeAndScheduleNextHeartbeatExpiration(GroupCoordinator.scala:795)
at
kafka.coordinator.group.GroupCoordinator.$anonfun$handleHeartbeat$2(GroupCoordinator.scala:543)
at
scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:253)
at kafka.coordinator.group.GroupMetadata.inLock(GroupMetadata.scala:209)
at
kafka.coordinator.group.GroupCoordinator.handleHeartbeat(GroupCoordinator.scala:516)
at kafka.server.KafkaApis.handleHeartbeatRequest(KafkaApis.scala:1617)
at kafka.server.KafkaApis.handle(KafkaApis.scala:155) {code}
Looking at the logs, I see a coordinator change just prior to this exception.
The group was first unloaded as the coordinator moved to another broker and
then was loaded again as the coordinator was moved back. I am guessing that
somehow the delayed heartbeat is retaining the reference to the old
GroupMetadata instance. Not sure exactly how this can happen though.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (KAFKA-8264) Flaky Test PlaintextConsumerTest#testLowMaxFetchSizeForRequestAndPartition
[
https://issues.apache.org/jira/browse/KAFKA-8264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Kozlovski reassigned KAFKA-8264:
--
Assignee: Stanislav Kozlovski
> Flaky Test PlaintextConsumerTest#testLowMaxFetchSizeForRequestAndPartition
> --
>
> Key: KAFKA-8264
> URL: https://issues.apache.org/jira/browse/KAFKA-8264
> Project: Kafka
> Issue Type: Bug
> Components: core, unit tests
>Affects Versions: 2.0.1, 2.3.0
>Reporter: Matthias J. Sax
>Assignee: Stanislav Kozlovski
>Priority: Critical
> Labels: flaky-test
> Fix For: 2.4.0
>
>
> [https://builds.apache.org/blue/organizations/jenkins/kafka-2.0-jdk8/detail/kafka-2.0-jdk8/252/tests]
> {quote}org.apache.kafka.common.errors.TopicExistsException: Topic 'topic3'
> already exists.{quote}
> STDOUT
>
> {quote}[2019-04-19 03:54:20,080] ERROR [ReplicaFetcher replicaId=1,
> leaderId=0, fetcherId=0] Error for partition __consumer_offsets-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:20,080] ERROR [ReplicaFetcher replicaId=2, leaderId=0,
> fetcherId=0] Error for partition __consumer_offsets-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:20,312] ERROR [ReplicaFetcher replicaId=2, leaderId=0,
> fetcherId=0] Error for partition topic-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:20,313] ERROR [ReplicaFetcher replicaId=2, leaderId=1,
> fetcherId=0] Error for partition topic-1 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:20,994] ERROR [ReplicaFetcher replicaId=1, leaderId=0,
> fetcherId=0] Error for partition topic-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:21,727] ERROR [ReplicaFetcher replicaId=0, leaderId=2,
> fetcherId=0] Error for partition topicWithNewMessageFormat-1 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:28,696] ERROR [ReplicaFetcher replicaId=0, leaderId=2,
> fetcherId=0] Error for partition __consumer_offsets-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:28,699] ERROR [ReplicaFetcher replicaId=1, leaderId=2,
> fetcherId=0] Error for partition __consumer_offsets-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:29,246] ERROR [ReplicaFetcher replicaId=0, leaderId=2,
> fetcherId=0] Error for partition topic-1 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:29,247] ERROR [ReplicaFetcher replicaId=0, leaderId=1,
> fetcherId=0] Error for partition topic-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:29,287] ERROR [ReplicaFetcher replicaId=1, leaderId=2,
> fetcherId=0] Error for partition topic-1 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:33,408] ERROR [ReplicaFetcher replicaId=0, leaderId=2,
> fetcherId=0] Error for partition __consumer_offsets-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:33,408] ERROR [ReplicaFetcher replicaId=1, leaderId=2,
> fetcherId=0] Error for partition __consumer_offsets-0 at offset 0
> (kafka.server.ReplicaFetcherThread:76)
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server
> does not host this topic-partition.
> [2019-04-19 03:54:33,655] ERROR [ReplicaFetcher replicaId=0,
[jira] [Created] (KAFKA-8894) Flaky org.apache.kafka.streams.integration.ResetIntegrationTest.testReprocessingFromFileAfterResetWithoutIntermediateUserTopic
Stanislav Kozlovski created KAFKA-8894:
--
Summary: Flaky
org.apache.kafka.streams.integration.ResetIntegrationTest.testReprocessingFromFileAfterResetWithoutIntermediateUserTopic
Key: KAFKA-8894
URL: https://issues.apache.org/jira/browse/KAFKA-8894
Project: Kafka
Issue Type: Improvement
Reporter: Stanislav Kozlovski
{code:java}
java.lang.AssertionError: Condition not met within timeout 3. Topics are
not expected after 3 milli seconds.
at org.apache.kafka.test.TestUtils.waitForCondition(TestUtils.java:376)
at org.apache.kafka.test.TestUtils.waitForCondition(TestUtils.java:353)
at
org.apache.kafka.streams.integration.utils.EmbeddedKafkaCluster.waitForRemainingTopics(EmbeddedKafkaCluster.java:298)
at
org.apache.kafka.streams.integration.AbstractResetIntegrationTest.assertInternalTopicsGotDeleted(AbstractResetIntegrationTest.java:589)
at
org.apache.kafka.streams.integration.AbstractResetIntegrationTest.testReprocessingFromFileAfterResetWithoutIntermediateUserTopic(AbstractResetIntegrationTest.java:399)
at
org.apache.kafka.streams.integration.ResetIntegrationTest.testReprocessingFromFileAfterResetWithoutIntermediateUserTopic(ResetIntegrationTest.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
[https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/24733/testReport/junit/org.apache.kafka.streams.integration/ResetIntegrationTest/testReprocessingFromFileAfterResetWithoutIntermediateUserTopic/]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (KAFKA-8895) Flaky org.apache.kafka.streams.integration.ResetIntegrationTest.testReprocessingFromDateTimeAfterResetWithoutIntermediateUserTopic
Stanislav Kozlovski created KAFKA-8895:
--
Summary: Flaky
org.apache.kafka.streams.integration.ResetIntegrationTest.testReprocessingFromDateTimeAfterResetWithoutIntermediateUserTopic
Key: KAFKA-8895
URL: https://issues.apache.org/jira/browse/KAFKA-8895
Project: Kafka
Issue Type: Improvement
Reporter: Stanislav Kozlovski
{code:java}
java.lang.AssertionError: Condition not met within timeout 3. Topics are
not expected after 3 milli seconds.
at org.apache.kafka.test.TestUtils.waitForCondition(TestUtils.java:376)
at org.apache.kafka.test.TestUtils.waitForCondition(TestUtils.java:353)
at
org.apache.kafka.streams.integration.utils.EmbeddedKafkaCluster.waitForRemainingTopics(EmbeddedKafkaCluster.java:298)
at
org.apache.kafka.streams.integration.AbstractResetIntegrationTest.assertInternalTopicsGotDeleted(AbstractResetIntegrationTest.java:589)
{code}
[https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/24733/testReport/junit/org.apache.kafka.streams.integration/ResetIntegrationTest/testReprocessingFromDateTimeAfterResetWithoutIntermediateUserTopic/]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (KAFKA-8893) Flaky ResetIntegrationTest. testReprocessingFromScratchAfterResetWithIntermediateUserTopic
Stanislav Kozlovski created KAFKA-8893:
--
Summary: Flaky ResetIntegrationTest.
testReprocessingFromScratchAfterResetWithIntermediateUserTopic
Key: KAFKA-8893
URL: https://issues.apache.org/jira/browse/KAFKA-8893
Project: Kafka
Issue Type: Improvement
Reporter: Stanislav Kozlovski
{code:java}
java.lang.AssertionError: Condition not met within timeout 6. Did not
receive all 10 records from topic outputTopic
at org.apache.kafka.test.TestUtils.waitForCondition(TestUtils.java:376)
at org.apache.kafka.test.TestUtils.waitForCondition(TestUtils.java:353)
at
org.apache.kafka.streams.integration.utils.IntegrationTestUtils.waitUntilMinKeyValueRecordsReceived(IntegrationTestUtils.java:506)
{code}
[https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/24733/testReport/junit/org.apache.kafka.streams.integration/ResetIntegrationTest/testReprocessingFromScratchAfterResetWithIntermediateUserTopic/]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-7658) Add KStream#toTable to the Streams DSL
[
https://issues.apache.org/jira/browse/KAFKA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927063#comment-16927063
]
Matthias J. Sax commented on KAFKA-7658:
There is no KIP for this yet. For details about the KIP process, see the wiki:
[https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals]
While I still think that this operator is quite special, I am not against
adding it. Becuase we support to cast a KTable to a KStream via #toStream()
(what is equally questionable), we might also allow to case a KStream to a
KTable.
> Add KStream#toTable to the Streams DSL
> --
>
> Key: KAFKA-7658
> URL: https://issues.apache.org/jira/browse/KAFKA-7658
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: Guozhang Wang
>Priority: Major
> Labels: needs-kip, newbie
>
> We'd like to add a new API to the KStream object of the Streams DSL:
> {code}
> KTable KStream.toTable()
> KTable KStream.toTable(Materialized)
> {code}
> The function re-interpret the event stream {{KStream}} as a changelog stream
> {{KTable}}. Note that this should NOT be treated as a syntax-sugar as a dummy
> {{KStream.reduce()}} function which always take the new value, as it has the
> following difference:
> 1) an aggregation operator of {{KStream}} is for aggregating a event stream
> into an evolving table, which will drop null-values from the input event
> stream; whereas a {{toTable}} function will completely change the semantics
> of the input stream from event stream to changelog stream, and null-values
> will still be serialized, and if the resulted bytes are also null they will
> be interpreted as "deletes" to the materialized KTable (i.e. tombstones in
> the changelog stream).
> 2) the aggregation result {{KTable}} will always be materialized, whereas
> {{toTable}} resulted KTable may only be materialized if the overloaded
> function with Materialized is used (and if optimization is turned on it may
> still be only logically materialized if the queryable name is not set).
> Therefore, for users who want to take a event stream into a changelog stream
> (no matter why they cannot read from the source topic as a changelog stream
> {{KTable}} at the beginning), they should be using this new API instead of
> the dummy reduction function.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (KAFKA-8878) Flaky Test AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
[
https://issues.apache.org/jira/browse/KAFKA-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bejeck resolved KAFKA-8878.
Resolution: Fixed
> Flaky Test AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
> -
>
> Key: KAFKA-8878
> URL: https://issues.apache.org/jira/browse/KAFKA-8878
> Project: Kafka
> Issue Type: Bug
> Components: streams, unit tests
>Affects Versions: 2.4.0
>Reporter: Matthias J. Sax
>Assignee: Chris Pettitt
>Priority: Major
> Labels: flaky-test
> Fix For: 2.4.0
>
>
> [https://builds.apache.org/blue/organizations/jenkins/kafka-trunk-jdk8/detail/kafka-trunk-jdk8/3887/tests]
> {quote}java.lang.AssertionError: Expected no ERROR message while closing
> assignedTasks, but got 1. First error: [AdminClient clientId=adminclient-67]
> Connection to node -1 (localhost/127.0.0.1:8080) could not be established.
> Broker may not be available.. Cause: N/A
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.kafka.streams.processor.internals.AssignedStreamsTasksTest.shouldCloseCleanlyWithSuspendedTaskAndEOS(AssignedStreamsTasksTest.java:555){quote}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (KAFKA-8878) Flaky Test AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
[
https://issues.apache.org/jira/browse/KAFKA-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bejeck updated KAFKA-8878:
---
Fix Version/s: 2.4.0
> Flaky Test AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
> -
>
> Key: KAFKA-8878
> URL: https://issues.apache.org/jira/browse/KAFKA-8878
> Project: Kafka
> Issue Type: Bug
> Components: streams, unit tests
>Affects Versions: 2.4.0
>Reporter: Matthias J. Sax
>Assignee: Chris Pettitt
>Priority: Major
> Labels: flaky-test
> Fix For: 2.4.0
>
>
> [https://builds.apache.org/blue/organizations/jenkins/kafka-trunk-jdk8/detail/kafka-trunk-jdk8/3887/tests]
> {quote}java.lang.AssertionError: Expected no ERROR message while closing
> assignedTasks, but got 1. First error: [AdminClient clientId=adminclient-67]
> Connection to node -1 (localhost/127.0.0.1:8080) could not be established.
> Broker may not be available.. Cause: N/A
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.kafka.streams.processor.internals.AssignedStreamsTasksTest.shouldCloseCleanlyWithSuspendedTaskAndEOS(AssignedStreamsTasksTest.java:555){quote}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (KAFKA-8878) Flaky Test AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
[
https://issues.apache.org/jira/browse/KAFKA-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bejeck updated KAFKA-8878:
---
Affects Version/s: 2.4.0
> Flaky Test AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
> -
>
> Key: KAFKA-8878
> URL: https://issues.apache.org/jira/browse/KAFKA-8878
> Project: Kafka
> Issue Type: Bug
> Components: streams, unit tests
>Affects Versions: 2.4.0
>Reporter: Matthias J. Sax
>Assignee: Chris Pettitt
>Priority: Major
> Labels: flaky-test
>
> [https://builds.apache.org/blue/organizations/jenkins/kafka-trunk-jdk8/detail/kafka-trunk-jdk8/3887/tests]
> {quote}java.lang.AssertionError: Expected no ERROR message while closing
> assignedTasks, but got 1. First error: [AdminClient clientId=adminclient-67]
> Connection to node -1 (localhost/127.0.0.1:8080) could not be established.
> Broker may not be available.. Cause: N/A
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.kafka.streams.processor.internals.AssignedStreamsTasksTest.shouldCloseCleanlyWithSuspendedTaskAndEOS(AssignedStreamsTasksTest.java:555){quote}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-8878) Flaky Test AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
[
https://issues.apache.org/jira/browse/KAFKA-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926880#comment-16926880
]
ASF GitHub Bot commented on KAFKA-8878:
---
bbejeck commented on pull request #7302: KAFKA-8878: Fix flaky test
AssignedStreamsTasksTest#shouldCloseCleanl…
URL: https://github.com/apache/kafka/pull/7302
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 AssignedStreamsTasksTest#shouldCloseCleanlyWithSuspendedTaskAndEOS
> -
>
> Key: KAFKA-8878
> URL: https://issues.apache.org/jira/browse/KAFKA-8878
> Project: Kafka
> Issue Type: Bug
> Components: streams, unit tests
>Reporter: Matthias J. Sax
>Assignee: Chris Pettitt
>Priority: Major
> Labels: flaky-test
>
> [https://builds.apache.org/blue/organizations/jenkins/kafka-trunk-jdk8/detail/kafka-trunk-jdk8/3887/tests]
> {quote}java.lang.AssertionError: Expected no ERROR message while closing
> assignedTasks, but got 1. First error: [AdminClient clientId=adminclient-67]
> Connection to node -1 (localhost/127.0.0.1:8080) could not be established.
> Broker may not be available.. Cause: N/A
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.kafka.streams.processor.internals.AssignedStreamsTasksTest.shouldCloseCleanlyWithSuspendedTaskAndEOS(AssignedStreamsTasksTest.java:555){quote}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-7658) Add KStream#toTable to the Streams DSL
[
https://issues.apache.org/jira/browse/KAFKA-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926817#comment-16926817
]
Aishwarya Pradeep Kumar commented on KAFKA-7658:
Hi, I'm new to kafka contribution and would be happy to look into it, has a KIP
been created for this issue?
I agree with [~mjsax], I've used Kafka Streams API in the past but never
encountered a use case for this, unless a user wants to use a function like
flatMap (or possibly branched their streams) on the stream and then convert it
to KTable.
Please elaborate if I am wrong.
> Add KStream#toTable to the Streams DSL
> --
>
> Key: KAFKA-7658
> URL: https://issues.apache.org/jira/browse/KAFKA-7658
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: Guozhang Wang
>Priority: Major
> Labels: needs-kip, newbie
>
> We'd like to add a new API to the KStream object of the Streams DSL:
> {code}
> KTable KStream.toTable()
> KTable KStream.toTable(Materialized)
> {code}
> The function re-interpret the event stream {{KStream}} as a changelog stream
> {{KTable}}. Note that this should NOT be treated as a syntax-sugar as a dummy
> {{KStream.reduce()}} function which always take the new value, as it has the
> following difference:
> 1) an aggregation operator of {{KStream}} is for aggregating a event stream
> into an evolving table, which will drop null-values from the input event
> stream; whereas a {{toTable}} function will completely change the semantics
> of the input stream from event stream to changelog stream, and null-values
> will still be serialized, and if the resulted bytes are also null they will
> be interpreted as "deletes" to the materialized KTable (i.e. tombstones in
> the changelog stream).
> 2) the aggregation result {{KTable}} will always be materialized, whereas
> {{toTable}} resulted KTable may only be materialized if the overloaded
> function with Materialized is used (and if optimization is turned on it may
> still be only logically materialized if the queryable name is not set).
> Therefore, for users who want to take a event stream into a changelog stream
> (no matter why they cannot read from the source topic as a changelog stream
> {{KTable}} at the beginning), they should be using this new API instead of
> the dummy reduction function.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-8747) Flaky Test ControllerEventManagerTest#testEventQueueTime
[
https://issues.apache.org/jira/browse/KAFKA-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926806#comment-16926806
]
ASF GitHub Bot commented on KAFKA-8747:
---
stanislavkozlovski commented on pull request #7320: KAFKA-8747: Fix the flaky
ControllerEventManagerTest#testEventQueueTimeQuery test
URL: https://github.com/apache/kafka/pull/7320
This patch adds retry functionality to the testEventQueueTime test assertion
The test has been flaky, presumably due to some race condition with Yammer's
JMX reporter and when the tested histogram metric gets updated.
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 ControllerEventManagerTest#testEventQueueTime
>
>
> Key: KAFKA-8747
> URL: https://issues.apache.org/jira/browse/KAFKA-8747
> Project: Kafka
> Issue Type: Bug
> Components: core, unit tests
>Affects Versions: 2.4.0
>Reporter: Matthias J. Sax
>Priority: Critical
> Labels: flaky-test
>
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/6671/testReport/junit/kafka.controller/ControllerEventManagerTest/testEventQueueTime/]
> {quote}java.lang.AssertionError: expected:<500.0> but was:<0.0> at
> org.junit.Assert.fail(Assert.java:89) at
> org.junit.Assert.failNotEquals(Assert.java:835) at
> org.junit.Assert.assertEquals(Assert.java:555) at
> org.junit.Assert.assertEquals(Assert.java:685) at
> kafka.controller.ControllerEventManagerTest.testEventQueueTime(ControllerEventManagerTest.scala:100){quote}
> STDOUT:
> {quote}[2019-08-01 18:51:09,815] ERROR [ControllerEventThread controllerId=0]
> Uncaught error processing event BrokerChange
> (kafka.controller.ControllerEventManager$ControllerEventThread:76)
> java.lang.NullPointerException at
> kafka.controller.ControllerEventManagerTest.$anonfun$testEventThatThrowsException$1(ControllerEventManagerTest.scala:112)
> at scala.Function0.apply$mcV$sp(Function0.scala:39) at
> kafka.controller.ControllerEventManagerTest$$anon$3.process(ControllerEventManagerTest.scala:126)
> at kafka.controller.QueuedEvent.process(ControllerEventManager.scala:53) at
> kafka.controller.ControllerEventManager$ControllerEventThread.$anonfun$doWork$1(ControllerEventManager.scala:137)
> at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23) at
> kafka.metrics.KafkaTimer.time(KafkaTimer.scala:31) at
> kafka.controller.ControllerEventManager$ControllerEventThread.doWork(ControllerEventManager.scala:137)
> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:89)
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (KAFKA-8892) Display the sorted configs in Kafka Configs Help Command.
[ https://issues.apache.org/jira/browse/KAFKA-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926593#comment-16926593 ] ASF GitHub Bot commented on KAFKA-8892: --- kamalcph commented on pull request #7319: KAFKA-8892: Display the sorted configs in Kafka Configs Help Command. URL: https://github.com/apache/kafka/pull/7319 ### 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 > Display the sorted configs in Kafka Configs Help Command. > - > > Key: KAFKA-8892 > URL: https://issues.apache.org/jira/browse/KAFKA-8892 > Project: Kafka > Issue Type: Bug >Reporter: Kamal Chandraprakash >Assignee: Kamal Chandraprakash >Priority: Minor > > Configs that can be updated dynamically for topics/brokers/users/clients are > shown in the help command. Only the topic configs are sorted alphabetically. > It will be helpful to do quick lookup if the brokers, users and clients > configs are also sorted. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8892) Display the sorted configs in Kafka Configs Help Command.
[ https://issues.apache.org/jira/browse/KAFKA-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Chandraprakash updated KAFKA-8892: Description: Configs that can be updated dynamically for topics/brokers/users/clients are shown in the help command. Only the topic configs are sorted alphabetically. It will be helpful to do quick lookup if the brokers, users and clients configs are also sorted. (was: Configs that can be updated dynamically for topics/brokers/users/clients are shown in the help command. Only the topic configs are sorted alphabetically. It will be useful to sort the brokers, users and clients configs also for quick lookup.) > Display the sorted configs in Kafka Configs Help Command. > - > > Key: KAFKA-8892 > URL: https://issues.apache.org/jira/browse/KAFKA-8892 > Project: Kafka > Issue Type: Bug >Reporter: Kamal Chandraprakash >Assignee: Kamal Chandraprakash >Priority: Minor > > Configs that can be updated dynamically for topics/brokers/users/clients are > shown in the help command. Only the topic configs are sorted alphabetically. > It will be helpful to do quick lookup if the brokers, users and clients > configs are also sorted. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (KAFKA-8892) Display the sorted configs in Kafka Configs Help Command.
Kamal Chandraprakash created KAFKA-8892: --- Summary: Display the sorted configs in Kafka Configs Help Command. Key: KAFKA-8892 URL: https://issues.apache.org/jira/browse/KAFKA-8892 Project: Kafka Issue Type: Bug Reporter: Kamal Chandraprakash Assignee: Kamal Chandraprakash Configs that can be updated dynamically for topics/brokers/users/clients are shown in the help command. Only the topic configs are sorted alphabetically. It will be useful to sort the brokers, users and clients configs also for quick lookup. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8891) invalid assignment protocol java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null
[ https://issues.apache.org/jira/browse/KAFKA-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SAIRAM KODURU updated KAFKA-8891: - Priority: Major (was: Trivial) > invalid assignment protocol java.lang.IllegalStateException: Coordinator > selected invalid assignment protocol: null > --- > > Key: KAFKA-8891 > URL: https://issues.apache.org/jira/browse/KAFKA-8891 > Project: Kafka > Issue Type: Bug >Reporter: SAIRAM KODURU >Priority: Major > > we are using 0.11.0.2 kafka client in our application. > we have observed the *below mentioned error* and got flooded with logs in > *crores*. > java.lang.IllegalStateException: Coordinator selected invalid assignment > protocol: null > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) > at > org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) > at > org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) > > But we are not able to reproduce the issue ? > we would like to know ,what are the possibilities of this error ? > How to handle this exception? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8891) invalid assignment protocol java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null
[ https://issues.apache.org/jira/browse/KAFKA-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SAIRAM KODURU updated KAFKA-8891: - Priority: Trivial (was: Major) > invalid assignment protocol java.lang.IllegalStateException: Coordinator > selected invalid assignment protocol: null > --- > > Key: KAFKA-8891 > URL: https://issues.apache.org/jira/browse/KAFKA-8891 > Project: Kafka > Issue Type: Bug >Reporter: SAIRAM KODURU >Priority: Trivial > > we are using 0.11.0.2 kafka client in our application. > we have observed the *below mentioned error* and got flooded with logs in > *crores*. > java.lang.IllegalStateException: Coordinator selected invalid assignment > protocol: null > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) > at > org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) > at > org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) > > But we are not able to reproduce the issue ? > we would like to know ,what are the possibilities of this error ? > How to handle this exception? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8891) invalid assignment protocol java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null
[ https://issues.apache.org/jira/browse/KAFKA-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SAIRAM KODURU updated KAFKA-8891: - Description: we are using 0.11.0.2 kafka client in our application. we have observed the *below mentioned error* and got flooded with logs in *crores*. java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) at org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) But we are not able to reproduce the issue ? we would like to know ,what are the possibilities of this error ? How to handle this exception? was: we are using 0.11.0.2 kafka client in our application. we have observed the *below mentioned error* and got flooded with logs in *crores*. java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) at org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) But we are not able to reproduce the issue again ? First would like to know ,what are the possibilities of this error ? > invalid assignment protocol java.lang.IllegalStateException: Coordinator > selected invalid assignment protocol: null > --- > > Key: KAFKA-8891 > URL: https://issues.apache.org/jira/browse/KAFKA-8891 > Project: Kafka > Issue Type: Bug >Reporter: SAIRAM KODURU >Priority: Major > > we are using 0.11.0.2 kafka client in our application. > we have observed the *below mentioned error* and got flooded with logs in > *crores*. > java.lang.IllegalStateException: Coordinator selected invalid assignment > protocol: null > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) > at > org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) > at > org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) > > But we are not able to reproduce the issue ? > we would like to know ,what are the possibilities of this error ? > How to handle this exception? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8891) invalid assignment protocoljava.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null
[ https://issues.apache.org/jira/browse/KAFKA-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SAIRAM KODURU updated KAFKA-8891: - Description: we are using 0.11.0.2 kafka client in our application. we have observed the *below mentioned error* and got flooded with logs in *crores*. java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) at org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) But we are not able to reproduce the issue again ? First would like to know ,what are the possibilities of this error ? Priority: Major (was: Minor) Summary: invalid assignment protocoljava.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null (was: invalid assignment protocol) > invalid assignment protocoljava.lang.IllegalStateException: Coordinator > selected invalid assignment protocol: null > -- > > Key: KAFKA-8891 > URL: https://issues.apache.org/jira/browse/KAFKA-8891 > Project: Kafka > Issue Type: Bug >Reporter: SAIRAM KODURU >Priority: Major > > we are using 0.11.0.2 kafka client in our application. > we have observed the *below mentioned error* and got flooded with logs in > *crores*. > java.lang.IllegalStateException: Coordinator selected invalid assignment > protocol: null > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) > at > org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) > at > org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) > > But we are not able to reproduce the issue again ? > First would like to know ,what are the possibilities of this error ? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8891) invalid assignment protocol java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null
[ https://issues.apache.org/jira/browse/KAFKA-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SAIRAM KODURU updated KAFKA-8891: - Summary: invalid assignment protocol java.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null (was: invalid assignment protocoljava.lang.IllegalStateException: Coordinator selected invalid assignment protocol: null) > invalid assignment protocol java.lang.IllegalStateException: Coordinator > selected invalid assignment protocol: null > --- > > Key: KAFKA-8891 > URL: https://issues.apache.org/jira/browse/KAFKA-8891 > Project: Kafka > Issue Type: Bug >Reporter: SAIRAM KODURU >Priority: Major > > we are using 0.11.0.2 kafka client in our application. > we have observed the *below mentioned error* and got flooded with logs in > *crores*. > java.lang.IllegalStateException: Coordinator selected invalid assignment > protocol: null > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinComplete(ConsumerCoordinator.java:218) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:367) > at > org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:316) > at > org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:297) > at > org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1078) > at > org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1043) > > But we are not able to reproduce the issue again ? > First would like to know ,what are the possibilities of this error ? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (KAFKA-8891) invalid assignment protocol
[ https://issues.apache.org/jira/browse/KAFKA-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SAIRAM KODURU updated KAFKA-8891: - Priority: Minor (was: Major) > invalid assignment protocol > --- > > Key: KAFKA-8891 > URL: https://issues.apache.org/jira/browse/KAFKA-8891 > Project: Kafka > Issue Type: Bug >Reporter: SAIRAM KODURU >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (KAFKA-8891) invalid assignment protocol
SAIRAM KODURU created KAFKA-8891: Summary: invalid assignment protocol Key: KAFKA-8891 URL: https://issues.apache.org/jira/browse/KAFKA-8891 Project: Kafka Issue Type: Bug Reporter: SAIRAM KODURU -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (KAFKA-8723) flaky test LeaderElectionCommandTest#testAllTopicPartition
[ https://issues.apache.org/jira/browse/KAFKA-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926363#comment-16926363 ] Levani Kokhreidze commented on KAFKA-8723: -- [https://builds.apache.org/blue/organizations/jenkins/kafka-pr-jdk11-scala2.13/detail/kafka-pr-jdk11-scala2.13/1542/pipeline] > flaky test LeaderElectionCommandTest#testAllTopicPartition > -- > > Key: KAFKA-8723 > URL: https://issues.apache.org/jira/browse/KAFKA-8723 > Project: Kafka > Issue Type: Bug >Reporter: Boyang Chen >Assignee: Stanislav Kozlovski >Priority: Major > > [https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/23737/console] > > *15:52:26* kafka.admin.LeaderElectionCommandTest > testAllTopicPartition > STARTED*15:53:08* kafka.admin.LeaderElectionCommandTest.testAllTopicPartition > failed, log available in > /home/jenkins/jenkins-slave/workspace/kafka-pr-jdk8-scala2.11@2/core/build/reports/testOutput/kafka.admin.LeaderElectionCommandTest.testAllTopicPartition.test.stdout*15:53:08* > *15:53:08* kafka.admin.LeaderElectionCommandTest > testAllTopicPartition > FAILED*15:53:08* kafka.common.AdminCommandFailedException: Timeout > waiting for election results*15:53:08* at > kafka.admin.LeaderElectionCommand$.electLeaders(LeaderElectionCommand.scala:133)*15:53:08* > at > kafka.admin.LeaderElectionCommand$.run(LeaderElectionCommand.scala:88)*15:53:08* > at > kafka.admin.LeaderElectionCommand$.main(LeaderElectionCommand.scala:41)*15:53:08* > at > kafka.admin.LeaderElectionCommandTest$$anonfun$testAllTopicPartition$1.apply(LeaderElectionCommandTest.scala:91)*15:53:08* > at > kafka.admin.LeaderElectionCommandTest$$anonfun$testAllTopicPartition$1.apply(LeaderElectionCommandTest.scala:74)*15:53:08* > at kafka.utils.TestUtils$.resource(TestUtils.scala:1588)*15:53:08* > at > kafka.admin.LeaderElectionCommandTest.testAllTopicPartition(LeaderElectionCommandTest.scala:74)*15:53:08* > *15:53:08* Caused by:*15:53:08* > org.apache.kafka.common.errors.TimeoutException: Aborted due to > timeout.*15:53:08* -- This message was sent by Atlassian Jira (v8.3.2#803003)
