[jira] [Commented] (KAFKA-8405) Remove deprecated preferred leader RPC and Command
[ https://issues.apache.org/jira/browse/KAFKA-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866235#comment-16866235 ] Sandeep commented on KAFKA-8405: [~jagsancio] I would like to work on this issue. As I understand, this is to remove all the classes/code references to the deprecated classes related to PreferredReplicaLeaderElectionCommand. Please let me know if there is anything wrong in my understanding > Remove deprecated preferred leader RPC and Command > -- > > Key: KAFKA-8405 > URL: https://issues.apache.org/jira/browse/KAFKA-8405 > Project: Kafka > Issue Type: Task > Components: admin >Affects Versions: 3.0.0 >Reporter: Jose Armando Garcia Sancio >Priority: Blocker > Fix For: 3.0.0 > > > For version 2.4.0, we deprecated: > # AdminClient.electPreferredLeaders > # ElectPreferredLeadersResult > # ElectPreferredLeadersOptions > # PreferredReplicaLeaderElectionCommand. > For version 3.0.0 we should remove all of this symbols and the reference to > them. For the command that includes: > # bin/kafka-preferred-replica-election.sh > # bin/windows/kafka-preferred-replica-election.bat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8551) Comments for connectors() in Herder interface
Luying Liu created KAFKA-8551: - Summary: Comments for connectors() in Herder interface Key: KAFKA-8551 URL: https://issues.apache.org/jira/browse/KAFKA-8551 Project: Kafka Issue Type: Bug Components: KafkaConnect Affects Versions: 2.2.1 Reporter: Luying Liu There are mistakes in the comments for connectors() in Herder interface. The mistakes are in the file [kafka|https://github.com/apache/kafka]/[connect|https://github.com/apache/kafka/tree/trunk/connect]/[runtime|https://github.com/apache/kafka/tree/trunk/connect/runtime]/[src|https://github.com/apache/kafka/tree/trunk/connect/runtime/src]/[main|https://github.com/apache/kafka/tree/trunk/connect/runtime/src/main]/[java|https://github.com/apache/kafka/tree/trunk/connect/runtime/src/main/java]/[org|https://github.com/apache/kafka/tree/trunk/connect/runtime/src/main/java/org]/[apache|https://github.com/apache/kafka/tree/trunk/connect/runtime/src/main/java/org/apache]/[kafka|https://github.com/apache/kafka/tree/trunk/connect/runtime/src/main/java/org/apache/kafka]/[connect|https://github.com/apache/kafka/tree/trunk/connect/runtime/src/main/java/org/apache/kafka/connect]/[runtime|https://github.com/apache/kafka/tree/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime]/*Herder.java.* -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-3556) Improve group coordinator metrics
[ https://issues.apache.org/jira/browse/KAFKA-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866189#comment-16866189 ] Boyang Chen commented on KAFKA-3556: [~guozhang] Sounds good, I found the rebalance duration/latency for each individual group pretty useful, because it's easier to monitor in a centralized location for the entire group status. Also, in terms of join/sync round trip latency, I wonder if we should focus on server side latency instead of client, because under current semantic, the time needed to propagate from stable to prepare rebalance and then to complete rebalance should be the dominant factor for round trip latency on client side. > Improve group coordinator metrics > - > > Key: KAFKA-3556 > URL: https://issues.apache.org/jira/browse/KAFKA-3556 > Project: Kafka > Issue Type: Improvement >Reporter: Jason Gustafson >Assignee: Liquan Pei >Priority: Major > > We currently don't have many metrics to track the behavior of the group > coordinator (especially with respect to the new consumer). On a quick pass, I > only saw a couple gauges in GroupMetadataManager for the number of groups and > the number of cached offsets. Here are some interesting metrics that may be > worth tracking: > 1. Session timeout rate > 2. Rebalance latency/rate > 3. Commit latency/rate > 4. Average group size > 5. Size of metadata cache > Some of these may also be interesting to track per group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8550) Connector validation fails with aliased converters
[ https://issues.apache.org/jira/browse/KAFKA-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866106#comment-16866106 ] ASF GitHub Bot commented on KAFKA-8550: --- C0urante commented on pull request #6959: KAFKA-8550: Fix plugin loading of aliased converters in Connect URL: https://github.com/apache/kafka/pull/6959 [Jira](https://issues.apache.org/jira/browse/KAFKA-8550) Summary of issue: connector validation fails if an alias is used for the converter since the validation for that is done via `ConfigDef.validateAll(...)`, which in turn invokes `Class.forName(...)` on the alias. Even though the class is successfully loaded by the `DelegatingClassLoader`, some Java implementations will refuse to return a class from `Class.forName(...)` whose name differs than the argument provided. Summary of fix: alter `ConfigDef.parseType(...)` to _first_ invoke `ClassLoader.loadClass(...)` on the class in order to get a handle on the actual class object to be loaded, _then_ invoke `Class.forName(...)` with the fully-qualified class name of the to-be-loaded class and return the result. The invocation of `Class.forName(...)` is necessary in order to allow static initialization to take place; simply calling `ClassLoader.loadClass(...)` is insufficient. Summary of testing: tested manually on trunk. Added unit test to `ConfigDefTest` that simulates the plugin-aliasing behavior of the `DelegatingClassLoader` and then invokes `ConfigDef.parseType` on an aliased class; this test fails on the current trunk but succeeds with the changes proposed here. This should be backported at _least_ to 2.0; it's likely the issue goes back further than that but since it's been around for so long and has yet to be noted by anyone else it doesn't seem worth the effort to backport that much further if there are any significant merge conflicts. ### 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 > Connector validation fails with aliased converters > -- > > Key: KAFKA-8550 > URL: https://issues.apache.org/jira/browse/KAFKA-8550 > Project: Kafka > Issue Type: Bug > Components: KafkaConnect >Affects Versions: 2.0.2, 2.3.0, 2.1.2, 2.2.2 >Reporter: Chris Egerton >Assignee: Chris Egerton >Priority: Major > > During connector config validation, > [ConfigDef.validateAll(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/clients/src/main/java/org/apache/kafka/common/config/ConfigDef.java#L497-L513] > is invoked using a [Connector > ConfigDef|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java]. > This ConfigDef contains definitions for the [key and value > converters|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L72-L78], > which have the type > [ConfigDef.Type.CLASS|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L167-L168]. > When plugin aliases are used for these configs, an error is encountered and > the connector configuration is rejected. > This error occurs because > [Class.forName(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader-] > is used to load the classes for these configs during validation. Even though > the DelegatingClassLoader used by Connect successfully loads the requested > class in its > [loadClass(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/DelegatingClassLoader.java#L358-L376] > method, some (if not all) implementations of the Java runtime will then > perform a check in their native Class.forName method to verify that the name > of the loaded class matches the requested class name. For example, see [this > section of > OpenJDK|https://github.com/openjdk/jdk/blob/515e7600df738ebf8c42d38e322def012385e1b9/src/hotspot/share/classfile/systemDictionary.cpp#L1508-L1528] > that performs the aforementioned check. > A few possible fixes that come to mind include
[jira] [Updated] (KAFKA-4600) Consumer proceeds on when ConsumerRebalanceListener fails
[ https://issues.apache.org/jira/browse/KAFKA-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sophie Blee-Goldman updated KAFKA-4600: --- Issue Type: Sub-task (was: Bug) Parent: KAFKA-8179 > Consumer proceeds on when ConsumerRebalanceListener fails > - > > Key: KAFKA-4600 > URL: https://issues.apache.org/jira/browse/KAFKA-4600 > Project: Kafka > Issue Type: Sub-task > Components: consumer >Affects Versions: 0.10.1.1 >Reporter: Braedon Vickers >Priority: Major > > One of the use cases for a ConsumerRebalanceListener is to load state > necessary for processing a partition when it is assigned. However, when > ConsumerRebalanceListener.onPartitionsAssigned() fails for some reason (i.e. > the state isn't loaded), the error is logged and the consumer proceeds on as > if nothing happened, happily consuming messages from the new partition. When > the state is relied upon for correct processing, this can be very bad, e.g. > data loss can occur. > It would be better if the error was propagated up so it could be dealt with > normally. At the very least the assignment should fail so the consumer > doesn't see any messages from the new partitions, and the rebalance can be > reattempted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (KAFKA-8392) Kafka broker leaks metric when partition leader moves to another node.
[ https://issues.apache.org/jira/browse/KAFKA-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang reassigned KAFKA-8392: Assignee: Tu Tran > Kafka broker leaks metric when partition leader moves to another node. > -- > > Key: KAFKA-8392 > URL: https://issues.apache.org/jira/browse/KAFKA-8392 > Project: Kafka > Issue Type: Bug > Components: metrics >Affects Versions: 2.2.0 >Reporter: Kamal Chandraprakash >Assignee: Tu Tran >Priority: Major > > When a partition leader moves from one node to another due to an imbalance in > leader.imbalance.per.broker.percentage, the old leader broker still emits the > static metric value. > Steps to reproduce: > 1. Create a cluster with 3 nodes. > 2. Create a topic with 2 partitions and RF=3 > 3. Generate some data using the console producer. > 4. Move any one of the partition from one node to another using > reassign-partitions and preferred-replica-election script. > 5. Generate some data using the console producer. > 6. Now all the 3 nodes emit bytesIn, bytesOut and MessagesIn for that topic. > Is it the expected behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8550) Connector validation fails with aliased converters
[ https://issues.apache.org/jira/browse/KAFKA-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866044#comment-16866044 ] Chris Egerton commented on KAFKA-8550: -- I've tested for this against the latest for branches 2.0 through trunk; the issue is present in all of them. It's probably present in pre-2.0 branches as well but I haven't actually confirmed that yet. > Connector validation fails with aliased converters > -- > > Key: KAFKA-8550 > URL: https://issues.apache.org/jira/browse/KAFKA-8550 > Project: Kafka > Issue Type: Bug > Components: KafkaConnect >Affects Versions: 2.0.2, 2.3.0, 2.1.2, 2.2.2 >Reporter: Chris Egerton >Assignee: Chris Egerton >Priority: Major > > During connector config validation, > [ConfigDef.validateAll(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/clients/src/main/java/org/apache/kafka/common/config/ConfigDef.java#L497-L513] > is invoked using a [Connector > ConfigDef|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java]. > This ConfigDef contains definitions for the [key and value > converters|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L72-L78], > which have the type > [ConfigDef.Type.CLASS|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L167-L168]. > When plugin aliases are used for these configs, an error is encountered and > the connector configuration is rejected. > This error occurs because > [Class.forName(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader-] > is used to load the classes for these configs during validation. Even though > the DelegatingClassLoader used by Connect successfully loads the requested > class in its > [loadClass(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/DelegatingClassLoader.java#L358-L376] > method, some (if not all) implementations of the Java runtime will then > perform a check in their native Class.forName method to verify that the name > of the loaded class matches the requested class name. For example, see [this > section of > OpenJDK|https://github.com/openjdk/jdk/blob/515e7600df738ebf8c42d38e322def012385e1b9/src/hotspot/share/classfile/systemDictionary.cpp#L1508-L1528] > that performs the aforementioned check. > A few possible fixes that come to mind include altering the connector > validation in the AbstractHerder class to not use the > ConfigDef.validateAll(...) method, or altering the logic used by the > ConfigDef in its validateAll method for configs of type ConfigDef.Type.CLASS > to use > [ClassLoader.loadClass(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#loadClass-java.lang.String-] > either instead of or in addition to Class.forName(...). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KAFKA-8550) Connector validation fails with aliased converters
[ https://issues.apache.org/jira/browse/KAFKA-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Egerton updated KAFKA-8550: - Affects Version/s: 2.2.2 2.1.2 2.0.2 > Connector validation fails with aliased converters > -- > > Key: KAFKA-8550 > URL: https://issues.apache.org/jira/browse/KAFKA-8550 > Project: Kafka > Issue Type: Bug > Components: KafkaConnect >Affects Versions: 2.0.2, 2.3.0, 2.1.2, 2.2.2 >Reporter: Chris Egerton >Assignee: Chris Egerton >Priority: Major > > During connector config validation, > [ConfigDef.validateAll(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/clients/src/main/java/org/apache/kafka/common/config/ConfigDef.java#L497-L513] > is invoked using a [Connector > ConfigDef|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java]. > This ConfigDef contains definitions for the [key and value > converters|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L72-L78], > which have the type > [ConfigDef.Type.CLASS|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L167-L168]. > When plugin aliases are used for these configs, an error is encountered and > the connector configuration is rejected. > This error occurs because > [Class.forName(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader-] > is used to load the classes for these configs during validation. Even though > the DelegatingClassLoader used by Connect successfully loads the requested > class in its > [loadClass(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/DelegatingClassLoader.java#L358-L376] > method, some (if not all) implementations of the Java runtime will then > perform a check in their native Class.forName method to verify that the name > of the loaded class matches the requested class name. For example, see [this > section of > OpenJDK|https://github.com/openjdk/jdk/blob/515e7600df738ebf8c42d38e322def012385e1b9/src/hotspot/share/classfile/systemDictionary.cpp#L1508-L1528] > that performs the aforementioned check. > A few possible fixes that come to mind include altering the connector > validation in the AbstractHerder class to not use the > ConfigDef.validateAll(...) method, or altering the logic used by the > ConfigDef in its validateAll method for configs of type ConfigDef.Type.CLASS > to use > [ClassLoader.loadClass(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#loadClass-java.lang.String-] > either instead of or in addition to Class.forName(...). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KAFKA-8550) Connector validation fails with aliased converters
[ https://issues.apache.org/jira/browse/KAFKA-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Egerton updated KAFKA-8550: - Affects Version/s: 2.3.0 > Connector validation fails with aliased converters > -- > > Key: KAFKA-8550 > URL: https://issues.apache.org/jira/browse/KAFKA-8550 > Project: Kafka > Issue Type: Bug > Components: KafkaConnect >Affects Versions: 2.3.0 >Reporter: Chris Egerton >Assignee: Chris Egerton >Priority: Major > > During connector config validation, > [ConfigDef.validateAll(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/clients/src/main/java/org/apache/kafka/common/config/ConfigDef.java#L497-L513] > is invoked using a [Connector > ConfigDef|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java]. > This ConfigDef contains definitions for the [key and value > converters|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L72-L78], > which have the type > [ConfigDef.Type.CLASS|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L167-L168]. > When plugin aliases are used for these configs, an error is encountered and > the connector configuration is rejected. > This error occurs because > [Class.forName(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader-] > is used to load the classes for these configs during validation. Even though > the DelegatingClassLoader used by Connect successfully loads the requested > class in its > [loadClass(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/DelegatingClassLoader.java#L358-L376] > method, some (if not all) implementations of the Java runtime will then > perform a check in their native Class.forName method to verify that the name > of the loaded class matches the requested class name. For example, see [this > section of > OpenJDK|https://github.com/openjdk/jdk/blob/515e7600df738ebf8c42d38e322def012385e1b9/src/hotspot/share/classfile/systemDictionary.cpp#L1508-L1528] > that performs the aforementioned check. > A few possible fixes that come to mind include altering the connector > validation in the AbstractHerder class to not use the > ConfigDef.validateAll(...) method, or altering the logic used by the > ConfigDef in its validateAll method for configs of type ConfigDef.Type.CLASS > to use > [ClassLoader.loadClass(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#loadClass-java.lang.String-] > either instead of or in addition to Class.forName(...). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6958) Allow to define custom processor names with KStreams DSL
[ https://issues.apache.org/jira/browse/KAFKA-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866023#comment-16866023 ] ASF GitHub Bot commented on KAFKA-6958: --- bbejeck commented on pull request #6412: KAFKA-6958: Overload KTable methods to allow to name operation name using the new Named class URL: https://github.com/apache/kafka/pull/6412 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 > Allow to define custom processor names with KStreams DSL > > > Key: KAFKA-6958 > URL: https://issues.apache.org/jira/browse/KAFKA-6958 > Project: Kafka > Issue Type: Improvement > Components: streams >Affects Versions: 1.1.0 >Reporter: Florian Hussonnois >Assignee: Florian Hussonnois >Priority: Minor > Labels: kip > > Currently, while building a new Topology through the KStreams DSL the > processors are automatically named. > The genarated names are prefixed depending of the operation (i.e > KSTREAM-SOURCE, KSTREAM-FILTER, KSTREAM-MAP, etc). > To debug/understand a topology it is possible to display the processor > lineage with the method Topology#describe(). However, a complex topology with > dozens of operations can be hard to understand if the processor names are not > relevant. > It would be useful to be able to set more meaningful names. For example, a > processor name could describe the business rule performed by a map() > operation. > [KIP-307|https://cwiki.apache.org/confluence/display/KAFKA/KIP-307%3A+Allow+to+define+custom+processor+names+with+KStreams+DSL] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8550) Connector validation fails with aliased converters
Chris Egerton created KAFKA-8550: Summary: Connector validation fails with aliased converters Key: KAFKA-8550 URL: https://issues.apache.org/jira/browse/KAFKA-8550 Project: Kafka Issue Type: Bug Components: KafkaConnect Reporter: Chris Egerton Assignee: Chris Egerton During connector config validation, [ConfigDef.validateAll(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/clients/src/main/java/org/apache/kafka/common/config/ConfigDef.java#L497-L513] is invoked using a [Connector ConfigDef|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java]. This ConfigDef contains definitions for the [key and value converters|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L72-L78], which have the type [ConfigDef.Type.CLASS|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L167-L168]. When plugin aliases are used for these configs, an error is encountered and the connector configuration is rejected. This error occurs because [Class.forName(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader-] is used to load the classes for these configs during validation. Even though the DelegatingClassLoader used by Connect successfully loads the requested class in its [loadClass(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/DelegatingClassLoader.java#L358-L376] method, some (if not all) implementations of the Java runtime will then perform a check in their native Class.forName method to verify that the name of the loaded class matches the requested class name. For example, see [this section of OpenJDK|https://github.com/openjdk/jdk/blob/515e7600df738ebf8c42d38e322def012385e1b9/src/hotspot/share/classfile/systemDictionary.cpp#L1508-L1528] that performs the aforementioned check. A few possible fixes that come to mind include altering the connector validation in the AbstractHerder class to not use the ConfigDef.validateAll(...) method, or altering the logic used by the ConfigDef in its validateAll method for configs of type ConfigDef.Type.CLASS to use [ClassLoader.loadClass(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#loadClass-java.lang.String-] either instead of or in addition to Class.forName(...). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8538) Add `group.instance.id` to DescribeGroup for better visibility
[ https://issues.apache.org/jira/browse/KAFKA-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866003#comment-16866003 ] ASF GitHub Bot commented on KAFKA-8538: --- abbccdda commented on pull request #6957: KAFKA-8538: add group.instance.id to DescribeGroup URL: https://github.com/apache/kafka/pull/6957 Include group.instance.id in the describe group result for better visibility. ### 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 > Add `group.instance.id` to DescribeGroup for better visibility > -- > > Key: KAFKA-8538 > URL: https://issues.apache.org/jira/browse/KAFKA-8538 > Project: Kafka > Issue Type: Sub-task >Reporter: Boyang Chen >Assignee: Boyang Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KAFKA-8539) Add `group.instance.id` to Subscription class
[ https://issues.apache.org/jira/browse/KAFKA-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson resolved KAFKA-8539. Resolution: Fixed Fix Version/s: 2.4.0 > Add `group.instance.id` to Subscription class > - > > Key: KAFKA-8539 > URL: https://issues.apache.org/jira/browse/KAFKA-8539 > Project: Kafka > Issue Type: Sub-task >Reporter: Boyang Chen >Assignee: Boyang Chen >Priority: Major > Fix For: 2.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8539) Add `group.instance.id` to Subscription class
[ https://issues.apache.org/jira/browse/KAFKA-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865852#comment-16865852 ] ASF GitHub Bot commented on KAFKA-8539: --- hachikuji commented on pull request #6936: KAFKA-8539 (part of KIP-345): add group.instance.id to Subscription URL: https://github.com/apache/kafka/pull/6936 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 > Add `group.instance.id` to Subscription class > - > > Key: KAFKA-8539 > URL: https://issues.apache.org/jira/browse/KAFKA-8539 > Project: Kafka > Issue Type: Sub-task >Reporter: Boyang Chen >Assignee: Boyang Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KAFKA-7853) Refactor ConsumerCoordinator/AbstractCoordinator to reduce constructor parameter list
[ https://issues.apache.org/jira/browse/KAFKA-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boyang Chen resolved KAFKA-7853. Resolution: Fixed > Refactor ConsumerCoordinator/AbstractCoordinator to reduce constructor > parameter list > - > > Key: KAFKA-7853 > URL: https://issues.apache.org/jira/browse/KAFKA-7853 > Project: Kafka > Issue Type: Improvement >Reporter: Boyang Chen >Assignee: Boyang Chen >Priority: Major > > The parameter lists for class ConsumerCoordinator/AbstractCoordinator are > growing over time. We should think of reducing the parameter size by > introducing some intermediate data structs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-7853) Refactor ConsumerCoordinator/AbstractCoordinator to reduce constructor parameter list
[ https://issues.apache.org/jira/browse/KAFKA-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865833#comment-16865833 ] ASF GitHub Bot commented on KAFKA-7853: --- guozhangwang commented on pull request #6854: KAFKA-7853: Refactor coordinator config URL: https://github.com/apache/kafka/pull/6854 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 > Refactor ConsumerCoordinator/AbstractCoordinator to reduce constructor > parameter list > - > > Key: KAFKA-7853 > URL: https://issues.apache.org/jira/browse/KAFKA-7853 > Project: Kafka > Issue Type: Improvement >Reporter: Boyang Chen >Assignee: Boyang Chen >Priority: Major > > The parameter lists for class ConsumerCoordinator/AbstractCoordinator are > growing over time. We should think of reducing the parameter size by > introducing some intermediate data structs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-3556) Improve group coordinator metrics
[ https://issues.apache.org/jira/browse/KAFKA-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865825#comment-16865825 ] Guozhang Wang commented on KAFKA-3556: -- Just my two cents: 1. I think latency metrics averaged over all groups may not be very helpful on the broker side, since one buggy group's signal may be buried with many other normal groups. On the other hand, average group size / metadata cache and rebalance / commit rate, as well as member session timeout rate can be maintained at broker-side. 2. On the consumer side, we can keep the rebalance rate, commit rate, and heartbeat timeout rate as well, plus the latency metrics, including rebalance latency, commit latency; and for rebalance latency I'd rather have a finer-grained split-up as well, e.g.: partition-revocation-callback latency, join-group-round-trip latency, sync-group-round-trip latency (would include the performAssignment callback as well), and partition-assignment-callback latency. This would also help testing the effectiveness of KIP-429 as well. > Improve group coordinator metrics > - > > Key: KAFKA-3556 > URL: https://issues.apache.org/jira/browse/KAFKA-3556 > Project: Kafka > Issue Type: Improvement >Reporter: Jason Gustafson >Assignee: Liquan Pei >Priority: Major > > We currently don't have many metrics to track the behavior of the group > coordinator (especially with respect to the new consumer). On a quick pass, I > only saw a couple gauges in GroupMetadataManager for the number of groups and > the number of cached offsets. Here are some interesting metrics that may be > worth tracking: > 1. Session timeout rate > 2. Rebalance latency/rate > 3. Commit latency/rate > 4. Average group size > 5. Size of metadata cache > Some of these may also be interesting to track per group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8450) Augment processed in MockProcessor as KeyValueAndTimestamp
[ https://issues.apache.org/jira/browse/KAFKA-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865819#comment-16865819 ] Guozhang Wang commented on KAFKA-8450: -- [~suryateja...@gmail.com] I did not find the PR link from this ticket; if you follow the PR procedure from `how to contribute` page then it should be auto-linked to the ticket. Could you share me the link? > Augment processed in MockProcessor as KeyValueAndTimestamp > -- > > Key: KAFKA-8450 > URL: https://issues.apache.org/jira/browse/KAFKA-8450 > Project: Kafka > Issue Type: Improvement > Components: streams, unit tests >Reporter: Guozhang Wang >Assignee: SuryaTeja Duggi >Priority: Major > Labels: newbie > > Today the book-keeping list of `processed` records in MockProcessor is in the > form of String, in which we just call the key / value type's toString > function in order to book-keep, this loses the type information as well as > not having timestamp associated with it. > It's better to translate its type to `KeyValueAndTimestamp` and refactor > impacted unit tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8525) Make log in Partion non-optional
[
https://issues.apache.org/jira/browse/KAFKA-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865789#comment-16865789
]
Vikas Singh commented on KAFKA-8525:
#2 was already done as part of KAFKA-8457. This Jira will only track the first
case above in description.
> Make log in Partion non-optional
>
>
> Key: KAFKA-8525
> URL: https://issues.apache.org/jira/browse/KAFKA-8525
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 2.3.0
>Reporter: Vikas Singh
>Assignee: Vikas Singh
>Priority: Minor
>
> While moving log out of replica to partition as part of KAFKA-8457 cleaned a
> bunch of code by removing code like "if (!localReplica) throw), there are
> still couple of additional cleanups that can be done:
> # The log object in Partition can be made non-optional. As it doesn't make
> sense to have a partition w/o log. Here is comment on PR for KAFKA-8457:
> {{I think it shouldn't be possible to have a Partition without a
> corresponding Log. Once this is merged, I think we can look into whether we
> can replace the optional log field in this class with a concrete instance.}}
> # The LocalReplica class can be removed simplifying replica class. Here is
> another comment on the PR: {{it might be possible to turn Replica into a
> trait and then let Log implement it directly. Then we could get rid of
> LocalReplica. That would also help us clean up RemoteReplica, since the usage
> of LogOffsetMetadata only makes sense for the local replica.}}
> Creating this JIRA to track these refactoring tasks for future.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (KAFKA-8450) Augment processed in MockProcessor as KeyValueAndTimestamp
[ https://issues.apache.org/jira/browse/KAFKA-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865781#comment-16865781 ] SuryaTeja Duggi edited comment on KAFKA-8450 at 6/17/19 5:05 PM: - [~mjsax] [~guozhang] merge the PR. was (Author: suryateja...@gmail.com): [~mjsax] [~guozhang] please merge the PR. > Augment processed in MockProcessor as KeyValueAndTimestamp > -- > > Key: KAFKA-8450 > URL: https://issues.apache.org/jira/browse/KAFKA-8450 > Project: Kafka > Issue Type: Improvement > Components: streams, unit tests >Reporter: Guozhang Wang >Assignee: SuryaTeja Duggi >Priority: Major > Labels: newbie > > Today the book-keeping list of `processed` records in MockProcessor is in the > form of String, in which we just call the key / value type's toString > function in order to book-keep, this loses the type information as well as > not having timestamp associated with it. > It's better to translate its type to `KeyValueAndTimestamp` and refactor > impacted unit tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8450) Augment processed in MockProcessor as KeyValueAndTimestamp
[ https://issues.apache.org/jira/browse/KAFKA-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865781#comment-16865781 ] SuryaTeja Duggi commented on KAFKA-8450: [~mjsax] [~guozhang] please merge the PR. > Augment processed in MockProcessor as KeyValueAndTimestamp > -- > > Key: KAFKA-8450 > URL: https://issues.apache.org/jira/browse/KAFKA-8450 > Project: Kafka > Issue Type: Improvement > Components: streams, unit tests >Reporter: Guozhang Wang >Assignee: SuryaTeja Duggi >Priority: Major > Labels: newbie > > Today the book-keeping list of `processed` records in MockProcessor is in the > form of String, in which we just call the key / value type's toString > function in order to book-keep, this loses the type information as well as > not having timestamp associated with it. > It's better to translate its type to `KeyValueAndTimestamp` and refactor > impacted unit tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KAFKA-8548) Inconsistency in Kafka Documentation
[
https://issues.apache.org/jira/browse/KAFKA-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias J. Sax resolved KAFKA-8548.
Resolution: Not A Problem
Closing this. The docs are correct as pointed out by [~ckamal].
> Inconsistency in Kafka Documentation
>
>
> Key: KAFKA-8548
> URL: https://issues.apache.org/jira/browse/KAFKA-8548
> Project: Kafka
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.2.1
>Reporter: Seweryn Habdank-Wojewodzki
>Priority: Minor
>
> Dears,
> Two parts (referenced below) of [documentation
> |http://kafka.apache.org/documentation/] are not quite consistent.
> In one text we can read, that max.poll.interval.ms has defaut value
> Integer.MAX_VALUE, in the other it is 300 000.
> Part 1.
> {quote}
> The default values for two configurations of the StreamsConfig class were
> changed to improve the resiliency of Kafka Streams applications. The internal
> Kafka Streams producer retries default value was changed from 0 to 10. The
> internal Kafka Streams consumer max.poll.interval.ms default value was
> changed from 30 to {color:#FF}Integer.MAX_VALUE{color}.
> {quote}
>
> Part 2. - Table
> |max.poll.interval.ms|The maximum delay between invocations of poll() when
> using consumer group management. This places an upper bound on the amount of
> time that the consumer can be idle before fetching more records. If poll() is
> not called before expiration of this timeout, then the consumer is considered
> failed and the group will rebalance in order to reassign the partitions to
> another member.|int|{color:#FF}30{color}|[1,...]|medium|
> Which value is then default :-)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (KAFKA-8457) Remove Log dependency from Replica
[ https://issues.apache.org/jira/browse/KAFKA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Singh resolved KAFKA-8457. Resolution: Fixed Fixed in commit 57baa4079d9fc14103411f790b9a025c9f2146a4 > Remove Log dependency from Replica > -- > > Key: KAFKA-8457 > URL: https://issues.apache.org/jira/browse/KAFKA-8457 > Project: Kafka > Issue Type: Bug > Components: core >Reporter: Vikas Singh >Assignee: Vikas Singh >Priority: Major > > A partition can have one log but many replicas. Putting log in replica meant > that we have to have if-else each time we need to access log. Moving the log > out of replica and in partition will make code simpler and it will also help > in testing where mocks will get simplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0
[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865744#comment-16865744 ] Jun Rao commented on KAFKA-8532: [~lbdai3190], if this issue happens again, it would be useful to take a few thread dumps and upload them in the jira. Thanks. > controller-event-thread deadlock with zk-session-expiry-handler0 > > > Key: KAFKA-8532 > URL: https://issues.apache.org/jira/browse/KAFKA-8532 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 2.1.1 >Reporter: leibo >Priority: Blocker > Attachments: js.log > > > We have observed a serious deadlock between controller-event-thead and > zk-session-expirey-handle thread. When this issue occurred, it's only one way > to recovery the kafka cluster is restart kafka server. The follows is the > jstack log of controller-event-thead and zk-session-expiry-handle thread. > "zk-session-expiry-handler0" #163089 daemon prio=5 os_prio=0 > tid=0x7fcc9c01 nid=0xfb22 waiting on condition [0x7fcbb01f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005ee3f7000> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) // > 等待controller-event-thread线程处理expireEvent > at > kafka.controller.KafkaController$Expire.waitUntilProcessingStarted(KafkaController.scala:1533) > at > kafka.controller.KafkaController$$anon$7.beforeInitializingSession(KafkaController.scala:173) > at > kafka.zookeeper.ZooKeeperClient.callBeforeInitializingSession(ZooKeeperClient.scala:408) > at > kafka.zookeeper.ZooKeeperClient.$anonfun$reinitialize$1(ZooKeeperClient.scala:374) > at > kafka.zookeeper.ZooKeeperClient.$anonfun$reinitialize$1$adapted(ZooKeeperClient.scala:374) > at kafka.zookeeper.ZooKeeperClient$$Lambda$1473/1823438251.apply(Unknown > Source) > at scala.collection.Iterator.foreach(Iterator.scala:937) > at scala.collection.Iterator.foreach$(Iterator.scala:937) > at scala.collection.AbstractIterator.foreach(Iterator.scala:1425) > at scala.collection.MapLike$DefaultValuesIterable.foreach(MapLike.scala:209) > at kafka.zookeeper.ZooKeeperClient.reinitialize(ZooKeeperClient.scala:374) > at > kafka.zookeeper.ZooKeeperClient.$anonfun$scheduleSessionExpiryHandler$1(ZooKeeperClient.scala:428) > at > kafka.zookeeper.ZooKeeperClient$$Lambda$1471/701792920.apply$mcV$sp(Unknown > Source) > at kafka.utils.KafkaScheduler.$anonfun$schedule$2(KafkaScheduler.scala:114) > at kafka.utils.KafkaScheduler$$Lambda$198/1048098469.apply$mcV$sp(Unknown > Source) > at kafka.utils.CoreUtils$$anon$1.run(CoreUtils.scala:63) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Locked ownable synchronizers: > - <0x000661e8d2e0> (a java.util.concurrent.ThreadPoolExecutor$Worker) > "controller-event-thread" #51 prio=5 os_prio=0 tid=0x7fceaeec4000 > nid=0x310 waiting on condition [0x7fccb55c8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005d1be5a00> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at
[jira] [Commented] (KAFKA-8546) Call System#runFinalization to avoid memory leak caused by JDK-6293787
[
https://issues.apache.org/jira/browse/KAFKA-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865734#comment-16865734
]
Lee Dongjin commented on KAFKA-8546:
[~ijuma] I inspected this issue a little bit. Although [~badai] described the
case of `GZIPInputStream` (which uses `Inflater` internally),
`GZIPOutputStream` (which uses `Deflater` internally) also has the same
vulnerability - `Deflater` also has `finalize` method like `Inflater`.
One possible strategy would be adding an internal implementation for Gzip
Streams (like `KafkaLZ4Block[Input,Output]Stream`), which calls
`System#runFinalization` on closing. As a note, I had implemented a similar
class when I was working on KAFKA-7632 (in this case, to support GZIP
compression level.)
How do you think? If the committers agree, I hope to take this issue.
[~badai] Thanks Badai, your description is so comprehensive and helpful.
> Call System#runFinalization to avoid memory leak caused by JDK-6293787
> --
>
> Key: KAFKA-8546
> URL: https://issues.apache.org/jira/browse/KAFKA-8546
> Project: Kafka
> Issue Type: Improvement
>Affects Versions: 2.0.1
>Reporter: Badai Aqrandista
>Priority: Minor
> Attachments: Screen Shot 2019-05-30 at 1.27.25 pm.png
>
>
> When a heavily used broker uses gzip compression on all topics, sometime you
> can hit GC pauses greater than zookeeper.session.timeout.ms of 6000ms. This
> is caused by memory leak caused by JDK-6293787
> ([https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6293787]), which is
> caused by JDK-4797189
> ([https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4797189]).
>
> In summary, this is what happen:
> * Inflater class contains finalizer method.
> * Whenever a class with finalizer method is instantiated, a Finalizer object
> is created.
> * GC finalizer thread is responsible to process all Finalizer objects.
> * If the rate of Finalizer object creation exceed the rate of GC finalizer
> thread ability to process it, Finalizer object number grows continuously, and
> eventually triggers full GC (because it is stored in Old Gen).
>
> Following stack trace shows what happen when a process is frozen doing full
> GC:
>
> {code:java}
> kafka-request-handler-13 Runnable Thread ID: 79
> java.util.zip.Inflater.inflateBytes(long, byte[], int, int) Inflater.java
> java.util.zip.Inflater.inflate(byte[], int, int) Inflater.java:259
> java.util.zip.InflaterInputStream.read(byte[], int, int)
> InflaterInputStream.java:152
> java.util.zip.GZIPInputStream.read(byte[], int, int)
> GZIPInputStream.java:117
> java.io.BufferedInputStream.fill() BufferedInputStream.java:246
> java.io.BufferedInputStream.read() BufferedInputStream.java:265
> java.io.DataInputStream.readByte() DataInputStream.java:265
> org.apache.kafka.common.utils.ByteUtils.readVarint(DataInput)
> ByteUtils.java:168
> org.apache.kafka.common.record.DefaultRecord.readFrom(DataInput, long,
> long, int, Long) DefaultRecord.java:292
> org.apache.kafka.common.record.DefaultRecordBatch$1.readNext(long, long,
> int, Long) DefaultRecordBatch.java:264
> org.apache.kafka.common.record.DefaultRecordBatch$RecordIterator.next()
> DefaultRecordBatch.java:563
> org.apache.kafka.common.record.DefaultRecordBatch$RecordIterator.next()
> DefaultRecordBatch.java:532
> org.apache.kafka.common.record.DefaultRecordBatch.iterator()
> DefaultRecordBatch.java:327
> scala.collection.convert.Wrappers$JIterableWrapper.iterator()
> Wrappers.scala:54
> scala.collection.IterableLike$class.foreach(IterableLike, Function1)
> IterableLike.scala:72
> scala.collection.AbstractIterable.foreach(Function1) Iterable.scala:54
>
> kafka.log.LogValidator$$anonfun$validateMessagesAndAssignOffsetsCompressed$1.apply(MutableRecordBatch)
> LogValidator.scala:267
>
> kafka.log.LogValidator$$anonfun$validateMessagesAndAssignOffsetsCompressed$1.apply(Object)
> LogValidator.scala:259
> scala.collection.Iterator$class.foreach(Iterator, Function1)
> Iterator.scala:891
> scala.collection.AbstractIterator.foreach(Function1) Iterator.scala:1334
> scala.collection.IterableLike$class.foreach(IterableLike, Function1)
> IterableLike.scala:72
> scala.collection.AbstractIterable.foreach(Function1) Iterable.scala:54
>
> kafka.log.LogValidator$.validateMessagesAndAssignOffsetsCompressed(MemoryRecords,
> LongRef, Time, long, CompressionCodec, CompressionCodec, boolean, byte,
> TimestampType, long, int, boolean) LogValidator.scala:259
> kafka.log.LogValidator$.validateMessagesAndAssignOffsets(MemoryRecords,
> LongRef, Time, long, CompressionCodec, CompressionCodec, boolean, byte,
> TimestampType, long, int, boolean) LogValidator.scala:70
> kafka.log.Log$$anonfun$append$2.liftedTree1$1(LogAppendInfo,
[jira] [Commented] (KAFKA-8457) Remove Log dependency from Replica
[ https://issues.apache.org/jira/browse/KAFKA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865716#comment-16865716 ] ASF GitHub Bot commented on KAFKA-8457: --- hachikuji commented on pull request #6841: KAFKA-8457: Move log from replica into partition URL: https://github.com/apache/kafka/pull/6841 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 > Remove Log dependency from Replica > -- > > Key: KAFKA-8457 > URL: https://issues.apache.org/jira/browse/KAFKA-8457 > Project: Kafka > Issue Type: Bug > Components: core >Reporter: Vikas Singh >Assignee: Vikas Singh >Priority: Major > > A partition can have one log but many replicas. Putting log in replica meant > that we have to have if-else each time we need to access log. Moving the log > out of replica and in partition will make code simpler and it will also help > in testing where mocks will get simplified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (KAFKA-8548) Inconsistency in Kafka Documentation
[
https://issues.apache.org/jira/browse/KAFKA-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865534#comment-16865534
]
Kamal Chandraprakash edited comment on KAFKA-8548 at 6/17/19 11:43 AM:
---
Part 1 is referring to Kafka Streams configuration. The `max.poll.interval.ms`
was over written to Integer.MAX_VALUE in Kafka Streams module. In Kafka 2.3.0,
this config is reduced to it's default 300 secs
(https://issues.apache.org/jira/browse/KAFKA-6399).
Part 2 is referring to the plain consumer group management where the default
value is 300 secs.
was (Author: ckamal):
Part 1 is referring to Kafka Streams configuration. The `max.poll.interval.ms`
was over written to Integer.MAX_VALUE in Kafka Streams module. In Kafka 2.3.0,
this config is reduced to it's default (300 secs).
Part 2 is referring to the plain consumer group management where the default
value is 300 secs.
> Inconsistency in Kafka Documentation
>
>
> Key: KAFKA-8548
> URL: https://issues.apache.org/jira/browse/KAFKA-8548
> Project: Kafka
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.2.1
>Reporter: Seweryn Habdank-Wojewodzki
>Priority: Minor
>
> Dears,
> Two parts (referenced below) of [documentation
> |http://kafka.apache.org/documentation/] are not quite consistent.
> In one text we can read, that max.poll.interval.ms has defaut value
> Integer.MAX_VALUE, in the other it is 300 000.
> Part 1.
> {quote}
> The default values for two configurations of the StreamsConfig class were
> changed to improve the resiliency of Kafka Streams applications. The internal
> Kafka Streams producer retries default value was changed from 0 to 10. The
> internal Kafka Streams consumer max.poll.interval.ms default value was
> changed from 30 to {color:#FF}Integer.MAX_VALUE{color}.
> {quote}
>
> Part 2. - Table
> |max.poll.interval.ms|The maximum delay between invocations of poll() when
> using consumer group management. This places an upper bound on the amount of
> time that the consumer can be idle before fetching more records. If poll() is
> not called before expiration of this timeout, then the consumer is considered
> failed and the group will rebalance in order to reassign the partitions to
> another member.|int|{color:#FF}30{color}|[1,...]|medium|
> Which value is then default :-)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KAFKA-8548) Inconsistency in Kafka Documentation
[
https://issues.apache.org/jira/browse/KAFKA-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865534#comment-16865534
]
Kamal Chandraprakash commented on KAFKA-8548:
-
Part 1 is referring to Kafka Streams configuration. The `max.poll.interval.ms`
was over written to Integer.MAX_VALUE in Kafka Streams module. In Kafka 2.3.0,
this config is reduced to it's default (300 secs).
Part 2 is referring to the plain consumer group management where the default
value is 300 secs.
> Inconsistency in Kafka Documentation
>
>
> Key: KAFKA-8548
> URL: https://issues.apache.org/jira/browse/KAFKA-8548
> Project: Kafka
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.2.1
>Reporter: Seweryn Habdank-Wojewodzki
>Priority: Minor
>
> Dears,
> Two parts (referenced below) of [documentation
> |http://kafka.apache.org/documentation/] are not quite consistent.
> In one text we can read, that max.poll.interval.ms has defaut value
> Integer.MAX_VALUE, in the other it is 300 000.
> Part 1.
> {quote}
> The default values for two configurations of the StreamsConfig class were
> changed to improve the resiliency of Kafka Streams applications. The internal
> Kafka Streams producer retries default value was changed from 0 to 10. The
> internal Kafka Streams consumer max.poll.interval.ms default value was
> changed from 30 to {color:#FF}Integer.MAX_VALUE{color}.
> {quote}
>
> Part 2. - Table
> |max.poll.interval.ms|The maximum delay between invocations of poll() when
> using consumer group management. This places an upper bound on the amount of
> time that the consumer can be idle before fetching more records. If poll() is
> not called before expiration of this timeout, then the consumer is considered
> failed and the group will rebalance in order to reassign the partitions to
> another member.|int|{color:#FF}30{color}|[1,...]|medium|
> Which value is then default :-)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0
[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865266#comment-16865266 ] leibo edited comment on KAFKA-8532 at 6/17/19 11:15 AM: [~ijuma] I have tried to reproduced this ,but failed, it will appear after i restart kafka cluster a few days. The following info may be helpful: # We are running kafka cluster into docker container managed by kubernetes. # Until now, every time this issue occurred, we found the zookeeper container CPU are set to 1C while the host have more than 50C CPU. # When we set to zookeeper container 1C cpu(The host have more than 50C cpu), due to docker's problem, the zookeeper running in docker container will have more than 38 GC work threads(According to JVM official document, 1C cpu should correspond 2 GC work threads), these gc work thread may slow down zookeeper , and maybe let kafka and zookeeper session timed out. # After we update zookeeper jvm *-XX:ParallelGCThreads=4* , this issue is not occurred yet, but I think this Optimizing measure is just reduce the probability of this problem, not solved it. According to above info, I think when this problem occurred , the zookeeper is not running well, and kafka cluster deadlock occurred, but after some time, zookeeper recover normal running, kafka is not . was (Author: lbdai3190): [~ijuma] I have tried to reproduced this ,but failed, it will appear after i restart kafka cluster a few days. The following info may be helpful: # We are running kafka cluster in to docker container managed by kubernetes. # Until now, every time this issue occurred, we found the zookeeper container CPU are set to 1C while the host have more than 50C CPU. # When we set to zookeeper container 1C cpu(The host have more than 50C cpu), due to docker's problem, the zookeeper running in docker container will have more than 38 GC work threads(According to JVM official document, 1C cpu should correspond 2 GC work threads), these gc work thread may slow down zookeeper , and maybe let kafka and zookeeper session timed out. # After we update zookeeper jvm *-XX:ParallelGCThreads=4* , this issue is not occurred yet, but I think this Optimizing measure is just reduce the probability of this problem, not solved it. According to above info, I think when this problem occurred , the zookeeper is not running well, and kafka cluster deadlock occurred, but after some time, zookeeper recover normal running, kafka is not . > controller-event-thread deadlock with zk-session-expiry-handler0 > > > Key: KAFKA-8532 > URL: https://issues.apache.org/jira/browse/KAFKA-8532 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 2.1.1 >Reporter: leibo >Priority: Blocker > Attachments: js.log > > > We have observed a serious deadlock between controller-event-thead and > zk-session-expirey-handle thread. When this issue occurred, it's only one way > to recovery the kafka cluster is restart kafka server. The follows is the > jstack log of controller-event-thead and zk-session-expiry-handle thread. > "zk-session-expiry-handler0" #163089 daemon prio=5 os_prio=0 > tid=0x7fcc9c01 nid=0xfb22 waiting on condition [0x7fcbb01f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005ee3f7000> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) // > 等待controller-event-thread线程处理expireEvent > at > kafka.controller.KafkaController$Expire.waitUntilProcessingStarted(KafkaController.scala:1533) > at > kafka.controller.KafkaController$$anon$7.beforeInitializingSession(KafkaController.scala:173) > at > kafka.zookeeper.ZooKeeperClient.callBeforeInitializingSession(ZooKeeperClient.scala:408) > at > kafka.zookeeper.ZooKeeperClient.$anonfun$reinitialize$1(ZooKeeperClient.scala:374) > at > kafka.zookeeper.ZooKeeperClient.$anonfun$reinitialize$1$adapted(ZooKeeperClient.scala:374) > at kafka.zookeeper.ZooKeeperClient$$Lambda$1473/1823438251.apply(Unknown > Source) > at scala.collection.Iterator.foreach(Iterator.scala:937) > at scala.collection.Iterator.foreach$(Iterator.scala:937) > at
[jira] [Updated] (KAFKA-8549) Kafka Windows start up fail due to cannot be performed on a file with a user-mapped section open
[
https://issues.apache.org/jira/browse/KAFKA-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prehistoricpenguin updated KAFKA-8549:
--
Summary: Kafka Windows start up fail due to cannot be performed on a file
with a user-mapped section open (was: Kafka Windows start up failed due to
cannot be performed on a file with a user-mapped section open)
> Kafka Windows start up fail due to cannot be performed on a file with a
> user-mapped section open
>
>
> Key: KAFKA-8549
> URL: https://issues.apache.org/jira/browse/KAFKA-8549
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 2.2.1
>Reporter: prehistoricpenguin
>Priority: Major
> Labels: crash, windows
>
> We are running Kafka server on windows, we got this exception during Kafka
> server start up:
> {code:java}
> 2019-06-11 14:50:48,537] ERROR Error while creating log for
> this_is_a_topic_name in dir C:\Program Files (x86)\dummy_path\tmp\kafka-logs
> (kafka.server.LogDirFailureChannel)
> java.io.IOException: The requested operation cannot be performed on a file
> with a user-mapped section open
> at java.io.RandomAccessFile.setLength(Native Method)
> at kafka.log.AbstractIndex.$anonfun$resize$1(AbstractIndex.scala:188)
> at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
> at kafka.log.AbstractIndex.resize(AbstractIndex.scala:175)
> at kafka.log.AbstractIndex.$anonfun$trimToValidSize$1(AbstractIndex.scala:238)
> at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
> at kafka.log.AbstractIndex.trimToValidSize(AbstractIndex.scala:238)
> at kafka.log.LogSegment.recover(LogSegment.scala:377)
> at kafka.log.Log.recoverSegment(Log.scala:500)
> at kafka.log.Log.$anonfun$loadSegmentFiles$3(Log.scala:482)
> at
> scala.collection.TraversableLike$WithFilter.$anonfun$foreach$1(TraversableLike.scala:792)
> at scala.collection.IndexedSeqOptimized.foreach(IndexedSeqOptimized.scala:36)
> at scala.collection.IndexedSeqOptimized.foreach$(IndexedSeqOptimized.scala:33)
> at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:198)
> at
> scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:791)
> at kafka.log.Log.loadSegmentFiles(Log.scala:454)
> at kafka.log.Log.$anonfun$loadSegments$1(Log.scala:565)
> at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
> at kafka.log.Log.retryOnOffsetOverflow(Log.scala:2034)
> at kafka.log.Log.loadSegments(Log.scala:559)
> at kafka.log.Log.(Log.scala:292)
> at kafka.log.Log$.apply(Log.scala:2168)
> at kafka.log.LogManager.$anonfun$getOrCreateLog$1(LogManager.scala:716)
> at scala.Option.getOrElse(Option.scala:138)
> at kafka.log.LogManager.getOrCreateLog(LogManager.scala:674)
> at kafka.cluster.Partition.$anonfun$getOrCreateReplica$1(Partition.scala:202)
> at kafka.utils.Pool$$anon$1.apply(Pool.scala:61)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
> at kafka.utils.Pool.getAndMaybePut(Pool.scala:60)
> at kafka.cluster.Partition.getOrCreateReplica(Partition.scala:198)
> at kafka.cluster.Partition.$anonfun$makeLeader$3(Partition.scala:376)
> at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:237)
> at scala.collection.Iterator.foreach(Iterator.scala:941)
> at scala.collection.Iterator.foreach$(Iterator.scala:941)
> at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
> at scala.collection.IterableLike.foreach(IterableLike.scala:74)
> at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
> at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
> at scala.collection.TraversableLike.map(TraversableLike.scala:237)
> at scala.collection.TraversableLike.map$(TraversableLike.scala:230)
> at scala.collection.AbstractTraversable.map(Traversable.scala:108)
> at kafka.cluster.Partition.$anonfun$makeLeader$1(Partition.scala:376)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
> at kafka.utils.CoreUtils$.inWriteLock(CoreUtils.scala:259)
> at kafka.cluster.Partition.makeLeader(Partition.scala:370)
> at
> kafka.server.ReplicaManager.$anonfun$makeLeaders$5(ReplicaManager.scala:1188)
> at scala.collection.mutable.HashMap.$anonfun$foreach$1(HashMap.scala:149)
> at scala.collection.mutable.HashTable.foreachEntry(HashTable.scala:237)
> at scala.collection.mutable.HashTable.foreachEntry$(HashTable.scala:230)
> at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:44)
> at scala.collection.mutable.HashMap.foreach(HashMap.scala:149)
> at kafka.server.ReplicaManager.makeLeaders(ReplicaManager.scala:1186)
> at
>
[jira] [Updated] (KAFKA-8549) Kafka Windows start up failed due to cannot be performed on a file with a user-mapped section open
[
https://issues.apache.org/jira/browse/KAFKA-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prehistoricpenguin updated KAFKA-8549:
--
Summary: Kafka Windows start up failed due to cannot be performed on a file
with a user-mapped section open (was: Kafka Windows start up failed due to
topic name conflict )
> Kafka Windows start up failed due to cannot be performed on a file with a
> user-mapped section open
> --
>
> Key: KAFKA-8549
> URL: https://issues.apache.org/jira/browse/KAFKA-8549
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 2.2.1
>Reporter: prehistoricpenguin
>Priority: Major
> Labels: crash, windows
>
> We are running Kafka server on windows, we got this exception during Kafka
> server start up:
> {code:java}
> 2019-06-11 14:50:48,537] ERROR Error while creating log for
> this_is_a_topic_name in dir C:\Program Files (x86)\dummy_path\tmp\kafka-logs
> (kafka.server.LogDirFailureChannel)
> java.io.IOException: The requested operation cannot be performed on a file
> with a user-mapped section open
> at java.io.RandomAccessFile.setLength(Native Method)
> at kafka.log.AbstractIndex.$anonfun$resize$1(AbstractIndex.scala:188)
> at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
> at kafka.log.AbstractIndex.resize(AbstractIndex.scala:175)
> at kafka.log.AbstractIndex.$anonfun$trimToValidSize$1(AbstractIndex.scala:238)
> at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
> at kafka.log.AbstractIndex.trimToValidSize(AbstractIndex.scala:238)
> at kafka.log.LogSegment.recover(LogSegment.scala:377)
> at kafka.log.Log.recoverSegment(Log.scala:500)
> at kafka.log.Log.$anonfun$loadSegmentFiles$3(Log.scala:482)
> at
> scala.collection.TraversableLike$WithFilter.$anonfun$foreach$1(TraversableLike.scala:792)
> at scala.collection.IndexedSeqOptimized.foreach(IndexedSeqOptimized.scala:36)
> at scala.collection.IndexedSeqOptimized.foreach$(IndexedSeqOptimized.scala:33)
> at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:198)
> at
> scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:791)
> at kafka.log.Log.loadSegmentFiles(Log.scala:454)
> at kafka.log.Log.$anonfun$loadSegments$1(Log.scala:565)
> at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
> at kafka.log.Log.retryOnOffsetOverflow(Log.scala:2034)
> at kafka.log.Log.loadSegments(Log.scala:559)
> at kafka.log.Log.(Log.scala:292)
> at kafka.log.Log$.apply(Log.scala:2168)
> at kafka.log.LogManager.$anonfun$getOrCreateLog$1(LogManager.scala:716)
> at scala.Option.getOrElse(Option.scala:138)
> at kafka.log.LogManager.getOrCreateLog(LogManager.scala:674)
> at kafka.cluster.Partition.$anonfun$getOrCreateReplica$1(Partition.scala:202)
> at kafka.utils.Pool$$anon$1.apply(Pool.scala:61)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
> at kafka.utils.Pool.getAndMaybePut(Pool.scala:60)
> at kafka.cluster.Partition.getOrCreateReplica(Partition.scala:198)
> at kafka.cluster.Partition.$anonfun$makeLeader$3(Partition.scala:376)
> at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:237)
> at scala.collection.Iterator.foreach(Iterator.scala:941)
> at scala.collection.Iterator.foreach$(Iterator.scala:941)
> at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
> at scala.collection.IterableLike.foreach(IterableLike.scala:74)
> at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
> at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
> at scala.collection.TraversableLike.map(TraversableLike.scala:237)
> at scala.collection.TraversableLike.map$(TraversableLike.scala:230)
> at scala.collection.AbstractTraversable.map(Traversable.scala:108)
> at kafka.cluster.Partition.$anonfun$makeLeader$1(Partition.scala:376)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
> at kafka.utils.CoreUtils$.inWriteLock(CoreUtils.scala:259)
> at kafka.cluster.Partition.makeLeader(Partition.scala:370)
> at
> kafka.server.ReplicaManager.$anonfun$makeLeaders$5(ReplicaManager.scala:1188)
> at scala.collection.mutable.HashMap.$anonfun$foreach$1(HashMap.scala:149)
> at scala.collection.mutable.HashTable.foreachEntry(HashTable.scala:237)
> at scala.collection.mutable.HashTable.foreachEntry$(HashTable.scala:230)
> at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:44)
> at scala.collection.mutable.HashMap.foreach(HashMap.scala:149)
> at kafka.server.ReplicaManager.makeLeaders(ReplicaManager.scala:1186)
> at
>
[jira] [Commented] (KAFKA-8328) Kafka smooth expansion
[ https://issues.apache.org/jira/browse/KAFKA-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865488#comment-16865488 ] ChenLin commented on KAFKA-8328: [~Yohan123] look forward to your reply，KIP url:[https://cwiki.apache.org/confluence/display/SHARDINGSPHERE/KIP-477%3AKafka+smooth+expansion] > Kafka smooth expansion > -- > > Key: KAFKA-8328 > URL: https://issues.apache.org/jira/browse/KAFKA-8328 > Project: Kafka > Issue Type: Improvement > Components: clients, core >Affects Versions: 0.10.2.0 >Reporter: ChenLin >Priority: Major > Labels: Kafka, expansion > Fix For: 0.10.2.0 > > Attachments: DiskUtil.png, Kafka_smooth_expansion.patch, > producerP999.png > > > When expanding the kafka cluster, the new follower will read the data from > the earliest offset. This can result in a large amount of historical data > being read from the disk, putting a lot of pressure on the disk and affecting > the performance of the kafka service, for example, the producer write latency > will increase. In general, kafka's original expansion mechanism has the > following problems: > 1. The new follower will put a lot of pressure on the disk; > 2. Causes the producer write latency to increase; > 3. Causes the consumer read latency to increase; > In order to solve these problems, we have proposed a solution for > smooth expansion. The main idea of the scheme is that the newly added > follower reads data from the HW position, and when the newly added follower > reads the data to a certain time threshold or data size threshold, the > follower enters the ISR queue. . Since the new follower reads data from the > HW location, most of the data read is in the operating system's cache, so it > does not put pressure on the disk and does not affect the performance of the > kafka service, thus solving the above problems. > In order to illustrate the problems of the original expansion scheme, > we have done some tests, and there are corresponding test charts in the > attachment. > !producerP999.png! > !DiskUtil.png! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8549) Kafka Windows start up failed due to topic name conflict
prehistoricpenguin created KAFKA-8549:
-
Summary: Kafka Windows start up failed due to topic name conflict
Key: KAFKA-8549
URL: https://issues.apache.org/jira/browse/KAFKA-8549
Project: Kafka
Issue Type: Bug
Components: core
Affects Versions: 2.2.1
Reporter: prehistoricpenguin
We are running Kafka server on windows, we got this exception during Kafka
server start up:
{code:java}
2019-06-11 14:50:48,537] ERROR Error while creating log for
this_is_a_topic_name in dir C:\Program Files (x86)\dummy_path\tmp\kafka-logs
(kafka.server.LogDirFailureChannel)
java.io.IOException: The requested operation cannot be performed on a file with
a user-mapped section open
at java.io.RandomAccessFile.setLength(Native Method)
at kafka.log.AbstractIndex.$anonfun$resize$1(AbstractIndex.scala:188)
at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
at kafka.log.AbstractIndex.resize(AbstractIndex.scala:175)
at kafka.log.AbstractIndex.$anonfun$trimToValidSize$1(AbstractIndex.scala:238)
at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
at kafka.log.AbstractIndex.trimToValidSize(AbstractIndex.scala:238)
at kafka.log.LogSegment.recover(LogSegment.scala:377)
at kafka.log.Log.recoverSegment(Log.scala:500)
at kafka.log.Log.$anonfun$loadSegmentFiles$3(Log.scala:482)
at
scala.collection.TraversableLike$WithFilter.$anonfun$foreach$1(TraversableLike.scala:792)
at scala.collection.IndexedSeqOptimized.foreach(IndexedSeqOptimized.scala:36)
at scala.collection.IndexedSeqOptimized.foreach$(IndexedSeqOptimized.scala:33)
at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:198)
at
scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:791)
at kafka.log.Log.loadSegmentFiles(Log.scala:454)
at kafka.log.Log.$anonfun$loadSegments$1(Log.scala:565)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at kafka.log.Log.retryOnOffsetOverflow(Log.scala:2034)
at kafka.log.Log.loadSegments(Log.scala:559)
at kafka.log.Log.(Log.scala:292)
at kafka.log.Log$.apply(Log.scala:2168)
at kafka.log.LogManager.$anonfun$getOrCreateLog$1(LogManager.scala:716)
at scala.Option.getOrElse(Option.scala:138)
at kafka.log.LogManager.getOrCreateLog(LogManager.scala:674)
at kafka.cluster.Partition.$anonfun$getOrCreateReplica$1(Partition.scala:202)
at kafka.utils.Pool$$anon$1.apply(Pool.scala:61)
at
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at kafka.utils.Pool.getAndMaybePut(Pool.scala:60)
at kafka.cluster.Partition.getOrCreateReplica(Partition.scala:198)
at kafka.cluster.Partition.$anonfun$makeLeader$3(Partition.scala:376)
at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:237)
at scala.collection.Iterator.foreach(Iterator.scala:941)
at scala.collection.Iterator.foreach$(Iterator.scala:941)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
at scala.collection.IterableLike.foreach(IterableLike.scala:74)
at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
at scala.collection.TraversableLike.map(TraversableLike.scala:237)
at scala.collection.TraversableLike.map$(TraversableLike.scala:230)
at scala.collection.AbstractTraversable.map(Traversable.scala:108)
at kafka.cluster.Partition.$anonfun$makeLeader$1(Partition.scala:376)
at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
at kafka.utils.CoreUtils$.inWriteLock(CoreUtils.scala:259)
at kafka.cluster.Partition.makeLeader(Partition.scala:370)
at kafka.server.ReplicaManager.$anonfun$makeLeaders$5(ReplicaManager.scala:1188)
at scala.collection.mutable.HashMap.$anonfun$foreach$1(HashMap.scala:149)
at scala.collection.mutable.HashTable.foreachEntry(HashTable.scala:237)
at scala.collection.mutable.HashTable.foreachEntry$(HashTable.scala:230)
at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:44)
at scala.collection.mutable.HashMap.foreach(HashMap.scala:149)
at kafka.server.ReplicaManager.makeLeaders(ReplicaManager.scala:1186)
at kafka.server.ReplicaManager.becomeLeaderOrFollower(ReplicaManager.scala:1098)
at kafka.server.KafkaApis.handleLeaderAndIsrRequest(KafkaApis.scala:195)
at kafka.server.KafkaApis.handle(KafkaApis.scala:112)
at kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:69)
at java.lang.Thread.run(Thread.java:748)
[2019-06-11 14:50:48,542] INFO [ReplicaManager broker=0] Stopping serving
replicas in dir C:\Program Files (x86)\dummy_path\tmp\kafka-logs
(kafka.server.ReplicaManager)
[2019-06-11 14:50:48,543] ERROR [ReplicaManager broker=0] Error while making
broker the leader for partition Topic: this_is_a_topic_name; Partition: 0;
Leader: None; AllReplicas: ; InSyncReplicas: in dir None
[jira] [Commented] (KAFKA-8537) Kafka issues after 2.1.0 upgrade: java.net.SocketTimeoutException: Failed to connect within 30000 ms
[
https://issues.apache.org/jira/browse/KAFKA-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865464#comment-16865464
]
Kamal Chandraprakash commented on KAFKA-8537:
-
[~Vinayzxzx]
This issue can happen when all the kafka-request-handler threads are busy and
not accepting the incoming requests. This is fixed in Kafka 2.1.1/2.2. Refer
https://issues.apache.org/jira/browse/KAFKA-7697 for more details.
> Kafka issues after 2.1.0 upgrade: java.net.SocketTimeoutException: Failed to
> connect within 3 ms
>
>
> Key: KAFKA-8537
> URL: https://issues.apache.org/jira/browse/KAFKA-8537
> Project: Kafka
> Issue Type: Bug
> Components: controller, core
>Affects Versions: 2.1.0
> Environment: RHEL Centos 7
>Reporter: VinayKumar
>Priority: Blocker
>
> After upgrading to 2.1.0 and added 2 nodes to existing kafka cluster, we are
> seeing below exceptions in all the kafka server nodes.
> Please assist on the below issue. We are facing this in production
> environment and its effecting the data.
>
> Below is the kafkaServer log:
> --
> java.net.SocketTimeoutException: Failed to connect within 3 ms
> at
> kafka.server.ReplicaFetcherBlockingSend.sendRequest(ReplicaFetcherBlockingSend.scala:93)
> at
> kafka.server.ReplicaFetcherThread.fetchFromLeader(ReplicaFetcherThread.scala:190)
> at
> kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:241)
> at
> kafka.server.AbstractFetcherThread.$anonfun$maybeFetch$3(AbstractFetcherThread.scala:130)
> at
> kafka.server.AbstractFetcherThread.$anonfun$maybeFetch$3$adapted(AbstractFetcherThread.scala:129)
> at scala.Option.foreach(Option.scala:257)
> at
> kafka.server.AbstractFetcherThread.maybeFetch(AbstractFetcherThread.scala:129)
> at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:111)
> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:82)
> [2019-06-13 13:32:50,779] INFO [ReplicaFetcher replicaId=0, leaderId=1,
> fetcherId=0] Error sending fetch request (sessionId=917670852, epoch=INITIAL)
> to node 1: java.net.SocketTimeoutException: Failed to connect within 3
> ms. (org.apache.kafka.clients.FetchSessionHandler)
> [2019-06-13 13:32:50,779] WARN [ReplicaFetcher replicaId=0, leaderId=1,
> fetcherId=0] Error in response for fetch request (type=FetchRequest,
> replicaId=0, maxWait=500, minBytes=1, maxBytes=10485760,
> fetchData=\{rsyslog_logstash-2=(offset=0, logStartOffset=0, maxBytes=1048576,
> currentLeaderEpoch=Optional[37]), __consumer_offsets-30=(offset=993338,
> logStartOffset=993338, maxBytes=1048576, currentLeaderEpoch=Optional[123]),
> artifactory-0=(offset=0, logStartOffset=0, maxBytes=1048576,
> currentLeaderEpoch=Optional[28]), __consumer_offsets-15=(offset=1587225971,
> logStartOffset=1587225971, maxBytes=1048576,
> currentLeaderEpoch=Optional[119]), canary-0=(offset=365, logStartOffset=365,
> maxBytes=1048576, currentLeaderEpoch=Optional[33]), dhcp-1=(offset=119100650,
> logStartOffset=117981376, maxBytes=1048576, currentLeaderEpoch=Optional[60]),
> network-rsyslog-0=(offset=28239623581, logStartOffset=28206340439,
> maxBytes=1048576, currentLeaderEpoch=Optional[43]),
> __consumer_offsets-10=(offset=521110, logStartOffset=521110,
> maxBytes=1048576, currentLeaderEpoch=Optional[129]),
> cyberark-2=(offset=2908230, logStartOffset=2884227, maxBytes=1048576,
> currentLeaderEpoch=Optional[83]), __consumer_offsets-35=(offset=3486700,
> logStartOffset=3486700, maxBytes=1048576, currentLeaderEpoch=Optional[107]),
> seclogs-1=(offset=4018313686, logStartOffset=4017261270, maxBytes=1048576,
> currentLeaderEpoch=Optional[91])}, isolationLevel=READ_UNCOMMITTED,
> toForget=, metadata=(sessionId=917670852, epoch=INITIAL))
> (kafka.server.ReplicaFetcherThread)
> java.net.SocketTimeoutException: Failed to connect within 3 ms
> at
> kafka.server.ReplicaFetcherBlockingSend.sendRequest(ReplicaFetcherBlockingSend.scala:93)
> at
> kafka.server.ReplicaFetcherThread.fetchFromLeader(ReplicaFetcherThread.scala:190)
> at
> kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:241)
> at
> kafka.server.AbstractFetcherThread.$anonfun$maybeFetch$3(AbstractFetcherThread.scala:130)
> at
> kafka.server.AbstractFetcherThread.$anonfun$maybeFetch$3$adapted(AbstractFetcherThread.scala:129)
> at scala.Option.foreach(Option.scala:257)
> at
> kafka.server.AbstractFetcherThread.maybeFetch(AbstractFetcherThread.scala:129)
> at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:111)
> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:82)
> [2019-06-13 13:33:22,781] INFO [ReplicaFetcher replicaId=0,
[jira] [Updated] (KAFKA-7375) Improve error messages verbosity
[
https://issues.apache.org/jira/browse/KAFKA-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seweryn Habdank-Wojewodzki updated KAFKA-7375:
--
Affects Version/s: 2.2.1
> Improve error messages verbosity
>
>
> Key: KAFKA-7375
> URL: https://issues.apache.org/jira/browse/KAFKA-7375
> Project: Kafka
> Issue Type: Task
>Affects Versions: 1.1.1, 2.2.1
>Reporter: Seweryn Habdank-Wojewodzki
>Priority: Major
>
> Dears,
> Very often when clients are trying to connect we see in Kafka logs:
> {code}
> “org.apache.kafka.common.network.SslTransportLayer - Failed to send SSL
> Close message“
> {code}
> The problem here is following: there is no word who? No IP, no client addres,
> nothing.
> Would be great to have in all error or warning reports like this one, very
> precize information which client has a problem, to be able to solve it. When
> the number of clients is more than 10, this message is completely useless and
> when there are even more clients it really spams logs.
> Thanks in advance for help.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (KAFKA-7214) Mystic FATAL error
[
https://issues.apache.org/jira/browse/KAFKA-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seweryn Habdank-Wojewodzki updated KAFKA-7214:
--
Affects Version/s: 2.2.1
> Mystic FATAL error
> --
>
> Key: KAFKA-7214
> URL: https://issues.apache.org/jira/browse/KAFKA-7214
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 0.11.0.3, 1.1.1, 2.2.1
>Reporter: Seweryn Habdank-Wojewodzki
>Priority: Critical
> Attachments: qns-1.1.zip, qns-1.zip
>
>
> Dears,
> Very often at startup of the streaming application I got exception:
> {code}
> Exception caught in process. taskId=0_1, processor=KSTREAM-SOURCE-00,
> topic=my_instance_medium_topic, partition=1, offset=198900203;
> [org.apache.kafka.streams.processor.internals.StreamTask.process(StreamTask.java:212),
>
> org.apache.kafka.streams.processor.internals.AssignedTasks$2.apply(AssignedTasks.java:347),
>
> org.apache.kafka.streams.processor.internals.AssignedTasks.applyToRunningTasks(AssignedTasks.java:420),
>
> org.apache.kafka.streams.processor.internals.AssignedTasks.process(AssignedTasks.java:339),
>
> org.apache.kafka.streams.processor.internals.StreamThread.processAndPunctuate(StreamThread.java:648),
>
> org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:513),
>
> org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:482),
>
> org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:459)]
> in thread
> my_application-my_instance-my_instance_medium-72ee1819-edeb-4d85-9d65-f67f7c321618-StreamThread-62
> {code}
> and then (without shutdown request from my side):
> {code}
> 2018-07-30 07:45:02 [ar313] [INFO ] StreamThread:912 - stream-thread
> [my_application-my_instance-my_instance-72ee1819-edeb-4d85-9d65-f67f7c321618-StreamThread-62]
> State transition from PENDING_SHUTDOWN to DEAD.
> {code}
> What is this?
> How to correctly handle it?
> Thanks in advance for help.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KAFKA-8548) Inconsistency in Kafka Documentation
Seweryn Habdank-Wojewodzki created KAFKA-8548:
-
Summary: Inconsistency in Kafka Documentation
Key: KAFKA-8548
URL: https://issues.apache.org/jira/browse/KAFKA-8548
Project: Kafka
Issue Type: Task
Components: documentation
Affects Versions: 2.2.1
Reporter: Seweryn Habdank-Wojewodzki
Dears,
Two parts (referenced below) of [documentation
|http://kafka.apache.org/documentation/] are not quite consistent.
In one text we can read, that max.poll.interval.ms has defaut value
Integer.MAX_VALUE, in the other it is 300 000.
Part 1.
{quote}
The default values for two configurations of the StreamsConfig class were
changed to improve the resiliency of Kafka Streams applications. The internal
Kafka Streams producer retries default value was changed from 0 to 10. The
internal Kafka Streams consumer max.poll.interval.ms default value was changed
from 30 to {color:#FF}Integer.MAX_VALUE{color}.
{quote}
Part 2. - Table
|max.poll.interval.ms|The maximum delay between invocations of poll() when
using consumer group management. This places an upper bound on the amount of
time that the consumer can be idle before fetching more records. If poll() is
not called before expiration of this timeout, then the consumer is considered
failed and the group will rebalance in order to reassign the partitions to
another member.|int|{color:#FF}30{color}|[1,...]|medium|
Which value is then default :-)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (KAFKA-4849) Bug in KafkaStreams documentation
[ https://issues.apache.org/jira/browse/KAFKA-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seweryn Habdank-Wojewodzki closed KAFKA-4849. - > Bug in KafkaStreams documentation > - > > Key: KAFKA-4849 > URL: https://issues.apache.org/jira/browse/KAFKA-4849 > Project: Kafka > Issue Type: Bug > Components: streams >Affects Versions: 0.10.2.0 >Reporter: Seweryn Habdank-Wojewodzki >Assignee: Matthias J. Sax >Priority: Minor > > At the page: https://kafka.apache.org/documentation/streams > > In the chapter titled Application Configuration and Execution, in the example > there is a line: > > settings.put(StreamsConfig.ZOOKEEPER_CONNECT_CONFIG, "zookeeper1:2181"); > > but ZOOKEEPER_CONNECT_CONFIG is deprecated in the Kafka version 0.10.2.0. > > Also the table on the page: > https://kafka.apache.org/0102/documentation/#streamsconfigs is a bit > misleading. > 1. Again zookeeper.connect is deprecated. > 2. The client.id and zookeeper.connect are marked by high importance, > but according to http://docs.confluent.io/3.2.0/streams/developer-guide.html > none of them are important to initialize the stream. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (KAFKA-6699) When one of two Kafka nodes are dead, streaming API cannot handle messaging
[ https://issues.apache.org/jira/browse/KAFKA-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seweryn Habdank-Wojewodzki closed KAFKA-6699. - > When one of two Kafka nodes are dead, streaming API cannot handle messaging > --- > > Key: KAFKA-6699 > URL: https://issues.apache.org/jira/browse/KAFKA-6699 > Project: Kafka > Issue Type: Bug > Components: streams >Affects Versions: 0.11.0.2 >Reporter: Seweryn Habdank-Wojewodzki >Priority: Major > > Dears, > I am observing quite often, when Kafka Broker is partly dead(*), then > application, which uses streaming API are doing nothing. > (*) Partly dead in my case it means that one of two Kafka nodes are out of > order. > Especially when disk is full on one machine, then Broker is going in some > strange state, where streaming API goes vacations. It seems like regular > producer/consumer API has no problem in such a case. > Can you have a look on that matter? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KAFKA-7697) Possible deadlock in kafka.cluster.Partition
[ https://issues.apache.org/jira/browse/KAFKA-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Chandraprakash updated KAFKA-7697: Description: After upgrading a fairly busy broker from 0.10.2.0 to 2.1.0, it locked up within a few minutes (by "locked up" I mean that all request handler threads were busy, and other brokers reported that they couldn't communicate with it). I restarted it a few times and it did the same thing each time. After downgrading to 0.10.2.0, the broker was stable. I attached a threaddump.txt from the last attempt on 2.1.0 that shows lots of kafka-request-handler- threads trying to acquire the leaderIsrUpdateLock lock in kafka.cluster.Partition. It jumps out that there are two threads that already have some read lock (can't tell which one) and are trying to acquire a second one (on two different read locks: 0x000708184b88 and 0x00070821f188): kafka-request-handler-1 and kafka-request-handler-4. Both are handling a produce request, and in the process of doing so, are calling Partition.fetchOffsetSnapshot while trying to complete a DelayedFetch. At the same time, both of those locks have writers from other threads waiting on them (kafka-request-handler-2 and kafka-scheduler-6). Neither of those locks appear to have writers that hold them (if only because no threads in the dump are deep enough in inWriteLock to indicate that). ReentrantReadWriteLock in nonfair mode prioritizes waiting writers over readers. Is it possible that kafka-request-handler-1 and kafka-request-handler-4 are each trying to read-lock the partition that is currently locked by the other one, and they're both parked waiting for kafka-request-handler-2 and kafka-scheduler-6 to get write locks, which they never will, because the former two threads own read locks and aren't giving them up? was: After upgrading a fairly busy broker from 0.10.2.0 to 2.1.0, it locked up within a few minutes (by "locked up" I mean that all request handler threads were busy, and other brokers reported that they couldn't communicate with it). I restarted it a few times and it did the same thing each time. After downgrading to 0.10.2.0, the broker was stable. I attached a thread dump from the last attempt on 2.1.0 that shows lots of kafka-request-handler- threads trying to acquire the leaderIsrUpdateLock lock in kafka.cluster.Partition. It jumps out that there are two threads that already have some read lock (can't tell which one) and are trying to acquire a second one (on two different read locks: 0x000708184b88 and 0x00070821f188): kafka-request-handler-1 and kafka-request-handler-4. Both are handling a produce request, and in the process of doing so, are calling Partition.fetchOffsetSnapshot while trying to complete a DelayedFetch. At the same time, both of those locks have writers from other threads waiting on them (kafka-request-handler-2 and kafka-scheduler-6). Neither of those locks appear to have writers that hold them (if only because no threads in the dump are deep enough in inWriteLock to indicate that). ReentrantReadWriteLock in nonfair mode prioritizes waiting writers over readers. Is it possible that kafka-request-handler-1 and kafka-request-handler-4 are each trying to read-lock the partition that is currently locked by the other one, and they're both parked waiting for kafka-request-handler-2 and kafka-scheduler-6 to get write locks, which they never will, because the former two threads own read locks and aren't giving them up? > Possible deadlock in kafka.cluster.Partition > > > Key: KAFKA-7697 > URL: https://issues.apache.org/jira/browse/KAFKA-7697 > Project: Kafka > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Gian Merlino >Assignee: Rajini Sivaram >Priority: Blocker > Fix For: 2.2.0, 2.1.1 > > Attachments: 322.tdump, kafka.log, kafka_jstack.txt, threaddump.txt > > > After upgrading a fairly busy broker from 0.10.2.0 to 2.1.0, it locked up > within a few minutes (by "locked up" I mean that all request handler threads > were busy, and other brokers reported that they couldn't communicate with > it). I restarted it a few times and it did the same thing each time. After > downgrading to 0.10.2.0, the broker was stable. I attached a threaddump.txt > from the last attempt on 2.1.0 that shows lots of kafka-request-handler- > threads trying to acquire the leaderIsrUpdateLock lock in > kafka.cluster.Partition. > It jumps out that there are two threads that already have some read lock > (can't tell which one) and are trying to acquire a second one (on two > different read locks: 0x000708184b88 and 0x00070821f188): > kafka-request-handler-1 and kafka-request-handler-4. Both are handling a > produce
