[jira] [Created] (KAFKA-8131) Add --version parameter to command line help outputs & docs
Sönke Liebau created KAFKA-8131: --- Summary: Add --version parameter to command line help outputs & docs Key: KAFKA-8131 URL: https://issues.apache.org/jira/browse/KAFKA-8131 Project: Kafka Issue Type: Improvement Components: tools Reporter: Sönke Liebau Assignee: Sönke Liebau KAFKA-2061 added the --version flag to kafka-run-class.sh which prints the Kafka version to the commandline. As this is in kafka-run-class.sh this will effectively work for all commandline tools that use this file to run a class, so it should be added to the help output of these scripts as well. A quick grep leads me to these suspects: * connect-distributed.sh * connect-standalone.sh * kafka-acls.sh * kafka-broker-api-versions.sh * kafka-configs.sh * kafka-console-consumer.sh * kafka-console-producer.sh * kafka-consumer-groups.sh * kafka-consumer-perf-test.sh * kafka-delegation-tokens.sh * kafka-delete-records.sh * kafka-dump-log.sh * kafka-log-dirs.sh * kafka-mirror-maker.sh * kafka-preferred-replica-election.sh * kafka-producer-perf-test.sh * kafka-reassign-partitions.sh * kafka-replica-verification.sh * kafka-server-start.sh * kafka-streams-application-reset.sh * kafka-topics.sh * kafka-verifiable-consumer.sh * kafka-verifiable-producer.sh * trogdor.sh * zookeeper-security-migration.sh * zookeeper-server-start.sh * zookeeper-shell.sh Currently this parameter is not documented at all, neither in the output nor in the official docs. I'd propose to add it to the docs as well as part of this issue, I'll look for a suitable place. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-7760) Add broker configuration to set minimum value for segment.bytes and segment.ms
[ https://issues.apache.org/jira/browse/KAFKA-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801472#comment-16801472 ] 洪朝阳 commented on KAFKA-7760: How can it get the broker config when creating a topic by using the TopicCommand class? It set min.topic.segment.bytes property when start a broker by the kafka.Kafka class. But than, how can it get this property when create a topic by the kafka.admin.TopicCommand class? Can it store this property in a public place, such as zookeeper? > Add broker configuration to set minimum value for segment.bytes and segment.ms > -- > > Key: KAFKA-7760 > URL: https://issues.apache.org/jira/browse/KAFKA-7760 > Project: Kafka > Issue Type: Improvement >Reporter: Badai Aqrandista >Priority: Major > Labels: kip, newbie > > If someone set segment.bytes or segment.ms at topic level to a very small > value (e.g. segment.bytes=1000 or segment.ms=1000), Kafka will generate a > very high number of segment files. This can bring down the whole broker due > to hitting the maximum open file (for log) or maximum number of mmap-ed file > (for index). > To prevent that from happening, I would like to suggest adding two new items > to the broker configuration: > * min.topic.segment.bytes, defaults to 1048576: The minimum value for > segment.bytes. When someone sets topic configuration segment.bytes to a value > lower than this, Kafka throws an error INVALID VALUE. > * min.topic.segment.ms, defaults to 360: The minimum value for > segment.ms. When someone sets topic configuration segment.ms to a value lower > than this, Kafka throws an error INVALID VALUE. > Thanks > Badai -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6181) Examining log messages with {{--deep-iteration}} should show superset of fields
[
https://issues.apache.org/jira/browse/KAFKA-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802420#comment-16802420
]
洪朝阳 commented on KAFKA-6181:
Although I am new to Kafka, I think it's a little easy.
> Examining log messages with {{--deep-iteration}} should show superset of
> fields
> ---
>
> Key: KAFKA-6181
> URL: https://issues.apache.org/jira/browse/KAFKA-6181
> Project: Kafka
> Issue Type: Improvement
> Components: core
>Affects Versions: 0.11.0.0
>Reporter: Yeva Byzek
>Priority: Minor
> Labels: newbie
>
> Printing log data on Kafka brokers using {{kafka.tools.DumpLogSegments}}:
> {{--deep-iteration}} should show a superset of fields in each message, as
> compared to without this parameter, however some fields are missing. Impact:
> users need to execute both commands to get the full set of fields.
> {noformat}
> kafka-run-class kafka.tools.DumpLogSegments \
> --print-data-log \
> --files .log
> Dumping .log
> Starting offset: 0
> baseOffset: 0 lastOffset: 35 baseSequence: -1 lastSequence: -1 producerId: -1
> producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false position: 0
> CreateTime: 1509987569448 isvalid: true size: 3985 magic: 2 compresscodec:
> NONE crc: 4227905507
> {noformat}
> {noformat}
> kafka-run-class kafka.tools.DumpLogSegments \
> --print-data-log \
> --files .log \
> --deep-iteration
> Dumping .log
> Starting offset: 0
> offset: 0 position: 0 CreateTime: 1509987569420 isvalid: true keysize: -1
> valuesize: 100
> magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional:
> false headerKeys: [] payload:
> SSXVNJHPDQDXVCRASTVYBCWVMGNYKRXVZXKGXTSPSJDGYLUEGQFLAQLOCFLJBEPOWFNSOMYARHAOPUFOJHHDXEHXJBHW
> {noformat}
> Notice, for example, that {{partitionLeaderEpoch}} and {{crc}} are missing.
> Print these and all missing fields.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (KAFKA-6181) Examining log messages with {{--deep-iteration}} should show superset of fields
[
https://issues.apache.org/jira/browse/KAFKA-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
洪朝阳 updated KAFKA-6181:
---
Comment: was deleted
(was: Although I am new to Kafka, I think it's a little easy.)
> Examining log messages with {{--deep-iteration}} should show superset of
> fields
> ---
>
> Key: KAFKA-6181
> URL: https://issues.apache.org/jira/browse/KAFKA-6181
> Project: Kafka
> Issue Type: Improvement
> Components: core
>Affects Versions: 0.11.0.0
>Reporter: Yeva Byzek
>Priority: Minor
> Labels: newbie
>
> Printing log data on Kafka brokers using {{kafka.tools.DumpLogSegments}}:
> {{--deep-iteration}} should show a superset of fields in each message, as
> compared to without this parameter, however some fields are missing. Impact:
> users need to execute both commands to get the full set of fields.
> {noformat}
> kafka-run-class kafka.tools.DumpLogSegments \
> --print-data-log \
> --files .log
> Dumping .log
> Starting offset: 0
> baseOffset: 0 lastOffset: 35 baseSequence: -1 lastSequence: -1 producerId: -1
> producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false position: 0
> CreateTime: 1509987569448 isvalid: true size: 3985 magic: 2 compresscodec:
> NONE crc: 4227905507
> {noformat}
> {noformat}
> kafka-run-class kafka.tools.DumpLogSegments \
> --print-data-log \
> --files .log \
> --deep-iteration
> Dumping .log
> Starting offset: 0
> offset: 0 position: 0 CreateTime: 1509987569420 isvalid: true keysize: -1
> valuesize: 100
> magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional:
> false headerKeys: [] payload:
> SSXVNJHPDQDXVCRASTVYBCWVMGNYKRXVZXKGXTSPSJDGYLUEGQFLAQLOCFLJBEPOWFNSOMYARHAOPUFOJHHDXEHXJBHW
> {noformat}
> Notice, for example, that {{partitionLeaderEpoch}} and {{crc}} are missing.
> Print these and all missing fields.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KAFKA-6181) Examining log messages with {{--deep-iteration}} should show superset of fields
[
https://issues.apache.org/jira/browse/KAFKA-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802423#comment-16802423
]
洪朝阳 commented on KAFKA-6181:
Hi, has this issue been closed? If not, can I pick it? I am very glad to pick
this.
> Examining log messages with {{--deep-iteration}} should show superset of
> fields
> ---
>
> Key: KAFKA-6181
> URL: https://issues.apache.org/jira/browse/KAFKA-6181
> Project: Kafka
> Issue Type: Improvement
> Components: core
>Affects Versions: 0.11.0.0
>Reporter: Yeva Byzek
>Priority: Minor
> Labels: newbie
>
> Printing log data on Kafka brokers using {{kafka.tools.DumpLogSegments}}:
> {{--deep-iteration}} should show a superset of fields in each message, as
> compared to without this parameter, however some fields are missing. Impact:
> users need to execute both commands to get the full set of fields.
> {noformat}
> kafka-run-class kafka.tools.DumpLogSegments \
> --print-data-log \
> --files .log
> Dumping .log
> Starting offset: 0
> baseOffset: 0 lastOffset: 35 baseSequence: -1 lastSequence: -1 producerId: -1
> producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false position: 0
> CreateTime: 1509987569448 isvalid: true size: 3985 magic: 2 compresscodec:
> NONE crc: 4227905507
> {noformat}
> {noformat}
> kafka-run-class kafka.tools.DumpLogSegments \
> --print-data-log \
> --files .log \
> --deep-iteration
> Dumping .log
> Starting offset: 0
> offset: 0 position: 0 CreateTime: 1509987569420 isvalid: true keysize: -1
> valuesize: 100
> magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional:
> false headerKeys: [] payload:
> SSXVNJHPDQDXVCRASTVYBCWVMGNYKRXVZXKGXTSPSJDGYLUEGQFLAQLOCFLJBEPOWFNSOMYARHAOPUFOJHHDXEHXJBHW
> {noformat}
> Notice, for example, that {{partitionLeaderEpoch}} and {{crc}} are missing.
> Print these and all missing fields.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (KAFKA-8160) To add ACL with SSL authentication
[ https://issues.apache.org/jira/browse/KAFKA-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau resolved KAFKA-8160. - Resolution: Information Provided Hi [~suseem...@gmail.com] you can absolutely use SSL based authentication with ACLs, please refer to the docs [here|https://kafka.apache.org/documentation/#security_ssl] and [here|https://kafka.apache.org/documentation/#security_authz] for more information. For your specific question, you will have to use a custom PrincipalBuilder to ensure that principals that are extracted from certificates conform to what you set as username for your SCRAM users. As this is more of a support request, not a new feature I'll close this ticket, if you have any further questions, please don't hesitate to reach out on the users mailing list! > To add ACL with SSL authentication > -- > > Key: KAFKA-8160 > URL: https://issues.apache.org/jira/browse/KAFKA-8160 > Project: Kafka > Issue Type: New Feature > Components: consumer, producer >Affects Versions: 1.1.0 >Reporter: suseendramani >Priority: Major > > We want to setup the SSL based authentication along with ACL in place. Is > that doable and can it be added as a feature ? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8170) To add kafka data at rest encryption
[ https://issues.apache.org/jira/browse/KAFKA-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803940#comment-16803940 ] Sönke Liebau commented on KAFKA-8170: - Hi [~ashelke], I've proposed [KIP-317|https://cwiki.apache.org/confluence/display/KAFKA/KIP-317%3A+Add+transparent+data+encryption+functionality] a while ago, which would probably cover this - though it would do so client-side. It has been dormant for a while now due to lots of other things to do on my end to be honest, but I plan on reviving this very shortly. > To add kafka data at rest encryption > > > Key: KAFKA-8170 > URL: https://issues.apache.org/jira/browse/KAFKA-8170 > Project: Kafka > Issue Type: New Feature > Components: log >Reporter: Akash >Priority: Minor > Labels: features, security > > Kafka have mechanism for wire encryption of data. > But the kafka data at rest which exist in /- > is still unencrypted. > This directories now have log files with actual messages embedded metadata, > but unauthorised user can still recover messages from this files > Addiding encryption for this data would be valuable for preventing message > protection from disk theft, unauthorised user access on servers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-7755) Kubernetes - Kafka clients are resolving DNS entries only one time
[ https://issues.apache.org/jira/browse/KAFKA-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811841#comment-16811841 ] Loïc Monney commented on KAFKA-7755: @Tim: This is not only specific to Kubernetes, but, as you suggested, this is affecting all environments where IP addresses of Kafka broker are changed at some time > Kubernetes - Kafka clients are resolving DNS entries only one time > -- > > Key: KAFKA-7755 > URL: https://issues.apache.org/jira/browse/KAFKA-7755 > Project: Kafka > Issue Type: Bug > Components: clients >Affects Versions: 2.1.0 > Environment: Kubernetes >Reporter: Loïc Monney >Priority: Blocker > Fix For: 2.2.0, 2.1.1 > > Attachments: pom.xml > > > *Introduction* > Since 2.1.0 Kafka clients are supporting multiple DNS resolved IP addresses > if the first one fails. This change has been introduced by > https://issues.apache.org/jira/browse/KAFKA-6863. However this DNS resolution > is now performed only one time by the clients. This is not a problem if all > brokers have fixed IP addresses, however this is definitely an issue when > Kafka brokers are run on top of Kubernetes. Indeed, new Kubernetes pods will > receive another IP address, so as soon as all brokers will have been > restarted clients won't be able to reconnect to any broker. > *Impact* > Everyone running Kafka 2.1 or later on top of Kubernetes is impacted when a > rolling restart is performed. > *Root cause* > Since https://issues.apache.org/jira/browse/KAFKA-6863 Kafka clients are > resolving DNS entries only once. > *Proposed solution* > In > [https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/ClusterConnectionStates.java#L368] > Kafka clients should perform the DNS resolution again when all IP addresses > have been "used" (when _index_ is back to 0) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8218) IllegalStateException while accessing context in Transformer
Bartłomiej Kępa created KAFKA-8218:
--
Summary: IllegalStateException while accessing context in
Transformer
Key: KAFKA-8218
URL: https://issues.apache.org/jira/browse/KAFKA-8218
Project: Kafka
Issue Type: Bug
Components: streams
Affects Versions: 2.1.1
Reporter: Bartłomiej Kępa
Custom Kotlin implementation of Transformer throws
{code}
java.lang.IllegalStateException: This should not happen as headers() should
only be called while a record is processed
{code}
while being plugged into the stream topology that actually works. Invocation of
transform() method has valid arguments (Key and GenericRecord).
The exception is being thrown because in our implementation of transform we
need to access headers from context.
{code:java}
override fun transform(key: String?, value: GenericRecord): KeyValue {
val headers = context.headers()
...
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KAFKA-8226) New MirrorMaker option partition.to.partition
Ernestas Vaiciukevičius created KAFKA-8226: -- Summary: New MirrorMaker option partition.to.partition Key: KAFKA-8226 URL: https://issues.apache.org/jira/browse/KAFKA-8226 Project: Kafka Issue Type: Improvement Components: core Reporter: Ernestas Vaiciukevičius Currently when MirrorMaker moves data between topics with records with null keys - it shuffles records between destination topic's partitions. Sometimes it's desirable trying to preserve the original partition. Related PR adds new command line option to do that: When partition.to.partition=true MirrorMaker retains the partition number when mirroring records even without the keys. When using this option - source and destination topics are assumed to have the same number of partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KAFKA-8226) New MirrorMaker option partition.to.partition
[ https://issues.apache.org/jira/browse/KAFKA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernestas Vaiciukevičius updated KAFKA-8226: --- Description: Currently when MirrorMaker moves data between topics with records with null keys - it shuffles records between destination topic's partitions. Sometimes it's desirable to try preserving the original partition. Related PR adds new command line option to do that: When partition.to.partition=true MirrorMaker retains the partition number when mirroring records even without the keys. When using this option - source and destination topics are assumed to have the same number of partitions. was: Currently when MirrorMaker moves data between topics with records with null keys - it shuffles records between destination topic's partitions. Sometimes it's desirable trying to preserve the original partition. Related PR adds new command line option to do that: When partition.to.partition=true MirrorMaker retains the partition number when mirroring records even without the keys. When using this option - source and destination topics are assumed to have the same number of partitions. > New MirrorMaker option partition.to.partition > - > > Key: KAFKA-8226 > URL: https://issues.apache.org/jira/browse/KAFKA-8226 > Project: Kafka > Issue Type: Improvement > Components: core >Reporter: Ernestas Vaiciukevičius >Priority: Major > > Currently when MirrorMaker moves data between topics with records with null > keys - it shuffles records between destination topic's partitions. Sometimes > it's desirable to try preserving the original partition. > Related PR adds new command line option to do that: > When partition.to.partition=true MirrorMaker retains the partition number > when mirroring records even without the keys. > When using this option - source and destination topics are assumed to have > the same number of partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8226) New MirrorMaker option partition.to.partition
[ https://issues.apache.org/jira/browse/KAFKA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817610#comment-16817610 ] Sönke Liebau commented on KAFKA-8226: - Hi [~ernisv], the functionality that you are implementing is definitely useful, however it can also easily be achieved by implementing a custom MessageHandler that preserves partitioning. Personally I think we should try to avoid adding too many features for which extensions point were already designed in Kafka. Additionally there is [MirrorMaker 2.0|[https://cwiki.apache.org/confluence/display/KAFKA/KIP-382%3A+MirrorMaker+2.0#KIP-382:MirrorMaker2.0-RemoteTopics,Partitions]] coming up, which I believe has this functionality built in. > New MirrorMaker option partition.to.partition > - > > Key: KAFKA-8226 > URL: https://issues.apache.org/jira/browse/KAFKA-8226 > Project: Kafka > Issue Type: Improvement > Components: core >Reporter: Ernestas Vaiciukevičius >Priority: Major > > Currently when MirrorMaker moves data between topics with records with null > keys - it shuffles records between destination topic's partitions. Sometimes > it's desirable to try preserving the original partition. > Related PR adds new command line option to do that: > When partition.to.partition=true MirrorMaker retains the partition number > when mirroring records even without the keys. > When using this option - source and destination topics are assumed to have > the same number of partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (KAFKA-8226) New MirrorMaker option partition.to.partition
[ https://issues.apache.org/jira/browse/KAFKA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817610#comment-16817610 ] Sönke Liebau edited comment on KAFKA-8226 at 4/15/19 7:14 AM: -- Hi [~ernisv], the functionality that you are implementing is definitely useful, however it can also easily be achieved by implementing a custom MessageHandler that preserves partitioning. Personally I think we should try to avoid adding too many features for which extensions point were already designed in Kafka. Additionally there is [MirrorMaker 2.0|https://cwiki.apache.org/confluence/display/KAFKA/KIP-382%3A+MirrorMaker+2.0#KIP-382:MirrorMaker2.0-RemoteTopics,Partitions] coming up, which I believe has this functionality built in. was (Author: sliebau): Hi [~ernisv], the functionality that you are implementing is definitely useful, however it can also easily be achieved by implementing a custom MessageHandler that preserves partitioning. Personally I think we should try to avoid adding too many features for which extensions point were already designed in Kafka. Additionally there is [MirrorMaker 2.0|https://cwiki.apache.org/confluence/display/KAFKA/KIP-382%3A+MirrorMaker+2.0#KIP-382:MirrorMaker2.0-RemoteTopics,Partitions]] coming up, which I believe has this functionality built in. > New MirrorMaker option partition.to.partition > - > > Key: KAFKA-8226 > URL: https://issues.apache.org/jira/browse/KAFKA-8226 > Project: Kafka > Issue Type: Improvement > Components: core >Reporter: Ernestas Vaiciukevičius >Priority: Major > > Currently when MirrorMaker moves data between topics with records with null > keys - it shuffles records between destination topic's partitions. Sometimes > it's desirable to try preserving the original partition. > Related PR adds new command line option to do that: > When partition.to.partition=true MirrorMaker retains the partition number > when mirroring records even without the keys. > When using this option - source and destination topics are assumed to have > the same number of partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (KAFKA-8226) New MirrorMaker option partition.to.partition
[ https://issues.apache.org/jira/browse/KAFKA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817610#comment-16817610 ] Sönke Liebau edited comment on KAFKA-8226 at 4/15/19 7:14 AM: -- Hi [~ernisv], the functionality that you are implementing is definitely useful, however it can also easily be achieved by implementing a custom MessageHandler that preserves partitioning. Personally I think we should try to avoid adding too many features for which extensions point were already designed in Kafka. Additionally there is [MirrorMaker 2.0|https://cwiki.apache.org/confluence/display/KAFKA/KIP-382%3A+MirrorMaker+2.0#KIP-382:MirrorMaker2.0-RemoteTopics,Partitions]] coming up, which I believe has this functionality built in. was (Author: sliebau): Hi [~ernisv], the functionality that you are implementing is definitely useful, however it can also easily be achieved by implementing a custom MessageHandler that preserves partitioning. Personally I think we should try to avoid adding too many features for which extensions point were already designed in Kafka. Additionally there is [MirrorMaker 2.0|[https://cwiki.apache.org/confluence/display/KAFKA/KIP-382%3A+MirrorMaker+2.0#KIP-382:MirrorMaker2.0-RemoteTopics,Partitions]] coming up, which I believe has this functionality built in. > New MirrorMaker option partition.to.partition > - > > Key: KAFKA-8226 > URL: https://issues.apache.org/jira/browse/KAFKA-8226 > Project: Kafka > Issue Type: Improvement > Components: core >Reporter: Ernestas Vaiciukevičius >Priority: Major > > Currently when MirrorMaker moves data between topics with records with null > keys - it shuffles records between destination topic's partitions. Sometimes > it's desirable to try preserving the original partition. > Related PR adds new command line option to do that: > When partition.to.partition=true MirrorMaker retains the partition number > when mirroring records even without the keys. > When using this option - source and destination topics are assumed to have > the same number of partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-1579) End-to-End tool to measure performance and correctness test
[ https://issues.apache.org/jira/browse/KAFKA-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817888#comment-16817888 ] Sönke Liebau commented on KAFKA-1579: - Hi [~raulcf] this has been open for a few years now without comments, are you still interested in picking up this piece of work? Otherwise I'd say we can close this down? > End-to-End tool to measure performance and correctness test > --- > > Key: KAFKA-1579 > URL: https://issues.apache.org/jira/browse/KAFKA-1579 > Project: Kafka > Issue Type: New Feature >Reporter: Raul Castro Fernandez >Assignee: Raul Castro Fernandez >Priority: Major > > Producer and Consumer tool that can: > - measure performance (throughput and RTT) > - test for atomic writes (AW) correctness > - test for read isolation/partition (RI/partition) correctness -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8246) refactor topic/group instance id validation condition
[ https://issues.apache.org/jira/browse/KAFKA-8246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819899#comment-16819899 ] Sönke Liebau commented on KAFKA-8246: - I believe that used to be a regular expression but was changed for better performance, see this [pull request|https://github.com/apache/kafka/pull/3234]. > refactor topic/group instance id validation condition > - > > Key: KAFKA-8246 > URL: https://issues.apache.org/jira/browse/KAFKA-8246 > Project: Kafka > Issue Type: Improvement >Reporter: Boyang Chen >Assignee: Boyang Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8247) Duplicate error handling in kafka-server-start.sh and actual Kafka class
Sönke Liebau created KAFKA-8247: --- Summary: Duplicate error handling in kafka-server-start.sh and actual Kafka class Key: KAFKA-8247 URL: https://issues.apache.org/jira/browse/KAFKA-8247 Project: Kafka Issue Type: Bug Components: core Affects Versions: 2.1.1 Reporter: Sönke Liebau There is some duplication of error handling for command line parameters that are passed into kafka-server-start.sh The shell script prints an error, if no arguments are passed in, effectively causing the same check in [Kafka|https://github.com/apache/kafka/blob/92db08cba582668d77160b0c2853efd45a1b809b/core/src/main/scala/kafka/Kafka.scala#L43] to never be triggered, unless the only option that is specified is -daemon, which would be removed before passing arguments to the java class. While not in any way critical I don't think that this is intended behavior. I think we should remove the extra check in kafka-server-start.sh and leave argument handling up to the Kafka class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8274) Old Committed messages got replayed after Kafka cluster Restart
[ https://issues.apache.org/jira/browse/KAFKA-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824252#comment-16824252 ] Sönke Liebau commented on KAFKA-8274: - hi [~hrishi_dypim], can you add some more detail around this issue if you have it? In principle this is something that is extensively tested for and should not occur. A few questions that come to mind: Was this a planned restart or did the cluster crash? Was the consumer group active immediately before the restart or was it inactive for a while? What clients are you using? How many messages were replayed? > Old Committed messages got replayed after Kafka cluster Restart > --- > > Key: KAFKA-8274 > URL: https://issues.apache.org/jira/browse/KAFKA-8274 > Project: Kafka > Issue Type: Bug > Components: consumer >Affects Versions: 1.0.0 > Environment: PROD >Reporter: Hrishikesh tiwary >Priority: Major > > I got a very serious issue in PROD Env . after restarting the Kafka cluster > my old committed messages by same group if got replayed. > Its very shocking that if messages are already committed by a group id then > how comes same messages will be replayed by same group id. > I have a consumer which runs in web based application, at start up it starts > the consumer by providing a group id. there is only one group id for the > given web app. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8247) Duplicate error handling in kafka-server-start.sh and actual Kafka class
[ https://issues.apache.org/jira/browse/KAFKA-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825442#comment-16825442 ] Sönke Liebau commented on KAFKA-8247: - Actually, upon further digging, the same check can also be found in the following scripts: * zookeeper-server-start.sh * zookeeper-shell.sh * connect-standalone.sh * connect-distributed.sh * kafka-run-class.sh I'll do some further digging, but suspect that we can remove all of these checks and simply leave parameter handling up to the executed classes themselves. > Duplicate error handling in kafka-server-start.sh and actual Kafka class > > > Key: KAFKA-8247 > URL: https://issues.apache.org/jira/browse/KAFKA-8247 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 2.1.1 >Reporter: Sönke Liebau >Priority: Minor > > There is some duplication of error handling for command line parameters that > are passed into kafka-server-start.sh > > The shell script prints an error, if no arguments are passed in, effectively > causing the same check in > [Kafka|https://github.com/apache/kafka/blob/92db08cba582668d77160b0c2853efd45a1b809b/core/src/main/scala/kafka/Kafka.scala#L43] > to never be triggered, unless the only option that is specified is -daemon, > which would be removed before passing arguments to the java class. > > While not in any way critical I don't think that this is intended behavior. I > think we should remove the extra check in kafka-server-start.sh and leave > argument handling up to the Kafka class. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8292) Add support for --version parameter to command line tools
Sönke Liebau created KAFKA-8292: --- Summary: Add support for --version parameter to command line tools Key: KAFKA-8292 URL: https://issues.apache.org/jira/browse/KAFKA-8292 Project: Kafka Issue Type: Improvement Reporter: Sönke Liebau During the implemenation of [KAFKA-8131|https://issues.apache.org/jira/browse/KAFKA-8131] we noticed that command line tools implement parsing of parameters in different ways. For most of the tools the --version parameter was correctly implemented in that issue, for the following this still remains to be done: * ConnectDistributed * ConnectStandalone * ProducerPerformance * VerifiableConsumer * VerifiableProducer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (KAFKA-8247) Duplicate error handling in kafka-server-start.sh and actual Kafka class
[ https://issues.apache.org/jira/browse/KAFKA-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau reassigned KAFKA-8247: --- Assignee: Sönke Liebau > Duplicate error handling in kafka-server-start.sh and actual Kafka class > > > Key: KAFKA-8247 > URL: https://issues.apache.org/jira/browse/KAFKA-8247 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 2.1.1 >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Minor > > There is some duplication of error handling for command line parameters that > are passed into kafka-server-start.sh > > The shell script prints an error, if no arguments are passed in, effectively > causing the same check in > [Kafka|https://github.com/apache/kafka/blob/92db08cba582668d77160b0c2853efd45a1b809b/core/src/main/scala/kafka/Kafka.scala#L43] > to never be triggered, unless the only option that is specified is -daemon, > which would be removed before passing arguments to the java class. > > While not in any way critical I don't think that this is intended behavior. I > think we should remove the extra check in kafka-server-start.sh and leave > argument handling up to the Kafka class. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8247) Duplicate error handling in kafka-server-start.sh and actual Kafka class
[ https://issues.apache.org/jira/browse/KAFKA-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835344#comment-16835344 ] Sönke Liebau commented on KAFKA-8247: - So..these checks actually have a little bit of sense, because the error message that is shown here is the only place where the -daemon parameter is documented that can be used to send tasks to the background. Since this parameter is handled in kafka-run-class it is honored by all command line tools though, regardless of whether this makes sense or not, so we might just add it in the default options next to --help and --version. Downside to this is that this will make the inconsistency between --help/version and -daemon glaringly obvious, not much we can do about that. I'm afraid there is no perfect solution here, handling parameters in two different places is just not possible in a clean way. I'll create a pull request to remove these duplicate checks for now, as it shouldn't break anything and fixes the immediate issue. > Duplicate error handling in kafka-server-start.sh and actual Kafka class > > > Key: KAFKA-8247 > URL: https://issues.apache.org/jira/browse/KAFKA-8247 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 2.1.1 >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Minor > > There is some duplication of error handling for command line parameters that > are passed into kafka-server-start.sh > > The shell script prints an error, if no arguments are passed in, effectively > causing the same check in > [Kafka|https://github.com/apache/kafka/blob/92db08cba582668d77160b0c2853efd45a1b809b/core/src/main/scala/kafka/Kafka.scala#L43] > to never be triggered, unless the only option that is specified is -daemon, > which would be removed before passing arguments to the java class. > > While not in any way critical I don't think that this is intended behavior. I > think we should remove the extra check in kafka-server-start.sh and leave > argument handling up to the Kafka class. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-7362) enable kafka broker to remove orphan partitions automatically
[ https://issues.apache.org/jira/browse/KAFKA-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836320#comment-16836320 ] Ferlin-Sutton Léo commented on KAFKA-7362: -- I can see the implementation is being worked on and discussed. In the meantime is there a recommended way to manually delete an orphan partition ? We were thinking of : # Stopping the Kafka process on the concerned broker # `rm -rf` the directory containing the orphaned partition # Turning the kafka broker back on > enable kafka broker to remove orphan partitions automatically > -- > > Key: KAFKA-7362 > URL: https://issues.apache.org/jira/browse/KAFKA-7362 > Project: Kafka > Issue Type: Improvement > Components: core, log >Reporter: xiongqi wu >Assignee: xiongqi wu >Priority: Major > > When partition reassignment removes topic partitions from a offline broker, > those removed partitions become orphan partitions to the broker. When the > offline broker comes back online, it is not able to clean up both data and > folders that belong to orphan partitions. Log manager will scan all all dirs > during startup, but the time based retention policy on a topic partition will > not be kicked out until the broker is either a follower or a leader of the > partition. In addition, we do not have logic to delete folders that belong > to orphan partition today. > Open this ticket to provide a mechanism (when enabled) to safely remove > orphan partitions automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8247) Duplicate error handling in kafka-server-start.sh and actual Kafka class
[
https://issues.apache.org/jira/browse/KAFKA-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837510#comment-16837510
]
Sönke Liebau commented on KAFKA-8247:
-
I've experimented a bit with this, I removed all those checks and diff'ed the
output of all shell scripts when ran without parameters.
See the results below, the number at the very end is the return code, but this
stays the same in all instances.
There is one additional script that differs: kafka-consumer-perf-test.sh - but
this is only because it has a random element in the output that changes every
run (how useful that is is another debate).
Overall this looks good to me, in some cases the output is even signicifantly
better, because we are not killing uage reporting from the java class anymore.
The output from the two connect classes might be improved a little I guess..
zookeeper-shell is a bit of a special case, as we change behavior by removing
this check. Currently it returns with a help message, without that check it
would default to connecting to localhost (behavior that I actually would
prefer).
If anybody has this call in a script somewhere this would hang post-change, as
it never returns. I'm not sure why someone would have that though, save for
testing purposes..
So overall I think we'd be good to make the change, unsure about Zookeeper
shell and the -daemon flag, anybody have an opinion on that?
Ping [~hachikuji] since you noticed this duplicate check as well.
{noformat}
==
./connect-distributed.sh.out
==
Old output:
USAGE: ./connect-distributed.sh [-daemon] connect-distributed.properties
0
-
New output:
[2019-05-10 09:53:16,310] INFO Usage: ConnectDistributed worker.properties
(org.apache.kafka.connect.cli.ConnectDistributed:64)
0
==
./connect-standalone.sh.out
==
Old output:
USAGE: ./connect-standalone.sh [-daemon] connect-standalone.properties
0
-
New output:
[2019-05-10 09:53:18,139] INFO Usage: ConnectStandalone worker.properties
connector1.properties [connector2.properties ...]
(org.apache.kafka.connect.cli.ConnectStandalone:62)
0
==
./kafka-run-class.sh.out
==
Old output:
USAGE: ./kafka-run-class.sh [-daemon] [-name servicename] [-loggc] classname
[opts]
0
-
New output:
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
-server to select the "server" VM
The default VM is server,
because you are running on a server-class machine.
-cp
-classpath
A : separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D=
set a system property
-verbose:[class|gc|jni]
enable verbose output
-version print product version and exit
-version:
Warning: this feature is deprecated and will be removed
in a future release.
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -no-jre-restrict-search
Warning: this feature is deprecated and will be removed
in a future release.
include/exclude user private JREs in the version search
-? -help print this help message
-Xprint help on non-standard options
-ea[:...|:]
-enableassertions[:...|:]
enable assertions with specified granularity
-da[:...|:]
-disableassertions[:...|:]
disable assertions with specified granularity
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:[=]
load native agent library , e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:[=]
load native agent library by full pathname
-javaagent:[=]
load Java programming language agent, see java.lang.instrument
-splash:
show splash screen with specified image
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for
more details.
0
==
./kafka-server-start.sh.out
==
Old output:
USAGE: ./kafka-server-start.sh [-daemon] server.properties [--override
property=value]*
0
-
New output:
[2019-05-10 09:53:58,855] INFO Registered kafka
[jira] [Commented] (KAFKA-8359) Reconsider default for leader imbalance percentage
[ https://issues.apache.org/jira/browse/KAFKA-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840262#comment-16840262 ] Sönke Liebau commented on KAFKA-8359: - I dug around a little as to where this default comes from, but the only thing that I could find is [this brief conversation|https://reviews.apache.org/r/15711/#comment56318]. Personally I think between the ability to customize this parameter, monitoring PreferredReplicaImbalanceCount and manually triggering a leader rebalance there is no real need to change the default behavior, but I am very happy to be convinced otherwise. Would it as an alternative be useful to make this parameter dynamically updateable without cluster restart? > Reconsider default for leader imbalance percentage > -- > > Key: KAFKA-8359 > URL: https://issues.apache.org/jira/browse/KAFKA-8359 > Project: Kafka > Issue Type: Improvement >Reporter: Dhruvil Shah >Priority: Major > > By default, the leader imbalance ratio is 10%. This means that the controller > won't trigger preferred leader election for a broker unless the ratio of the > number of partitions a broker is the current leader of and the number of > partitions it is the preferred leader of is off by more than 10%. The problem > is when a broker is catching up after a restart, the smallest topics tend to > catch up first and the largest ones later, so the 10% remaining difference > may not be proportional to the broker's load. To keep better balance in the > cluster, we should consider setting > `leader.imbalance.per.broker.percentage=0` by default so that the preferred > leaders are always elected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8163) SetSchemaMetadata SMT does not apply to nested types
[
https://issues.apache.org/jira/browse/KAFKA-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841564#comment-16841564
]
Marc Löhe commented on KAFKA-8163:
--
I experience the same problem with Connect 2.2 and Debezium 0.9.5.
Not sure if this is implemented Connect or Debezium, though?
> SetSchemaMetadata SMT does not apply to nested types
>
>
> Key: KAFKA-8163
> URL: https://issues.apache.org/jira/browse/KAFKA-8163
> Project: Kafka
> Issue Type: Bug
>Reporter: pierre bouvret
>Priority: Minor
>
> In a schema, I want to replace the pg.public.foufou namespace by the
> pg.other_public.foufou namespace.
> The schema (Envelope from Debezium) has an inner definition for Value also
> belonging to the pg.public.foufou namespace
> Using a SetSchemaMetadata SMT, the inner namespace is not updated.
> {quote}{
> "type": "record",
> "name": "Envelope",
> "namespace": "pg.other_public.foufou",
> "fields": [
> {
> "name": "before",
> "type": [
> "null",
> {
> "type": "record",
> "name": "Value",
> "namespace": "pg.public.foufou",
> "fields": [
> {
> "name": "id",
> "type": "int"
> },
> {
> "name": "lib",
> "type": [
> "null",
> "string"
> ],
> "default": null
> }
> ],
> "connect.name": "pg.public.foufou.Value"
> }
> ],
> "default": null
> },{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KAFKA-8393) Kafka Connect: Kafka Connect: could not get type for name org.osgi.framework.BundleListener on Windows
Loïc created KAFKA-8393: --- Summary: Kafka Connect: Kafka Connect: could not get type for name org.osgi.framework.BundleListener on Windows Key: KAFKA-8393 URL: https://issues.apache.org/jira/browse/KAFKA-8393 Project: Kafka Issue Type: Bug Components: KafkaConnect Affects Versions: 2.2.0 Environment: Windows 10 Reporter: Loïc Hi guys, according the documentation [https://kafka.apache.org/quickstart#quickstart_kafkaconnect] I've tried the command `c:\dev\Tools\servers\kafka_2.12-2.2.0>bin\windows\connect-standalone.bat config\connect-standalone.properties config\connect-file-source.properties config\connect-file-sink.properties` and got this error: c:\dev\Tools\servers\kafka_2.12-2.2.0>bin\windows\connect-standalone.bat config\connect-standalone.properties config\connect-file-source.properties config\connect-file-sink.properties [2019-05-17 10:21:25,049] WARN could not get type for name org.osgi.framework.BundleListener from any class loader (org.reflections.Reflections) org.reflections.ReflectionsException: could not get type for name org.osgi.framework.BundleListener at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:390) at org.reflections.Reflections.expandSuperTypes(Reflections.java:381) at org.reflections.Reflections.(Reflections.java:126) at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader$InternalReflections.(DelegatingClassLoader.java:400) at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.scanPluginPath(DelegatingClassLoader.java:299) at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.scanUrlsAndAddPlugins(DelegatingClassLoader.java:237) at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.initPluginLoader(DelegatingClassLoader.java:185) Environment: Windows 10, Kafka 2.12-2.2.0 [current] Many thanks for your help. Regards Loïc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6983) Error while deleting segments - The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/KAFKA-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849545#comment-16849545
]
Gérald Quintana commented on KAFKA-6983:
Still occurs on Kafka 2.2.0.
It makes developping Kafka Streams applications on Windows really complicated.
As the Kafka brokers are killed by this error.
{noformat}
[2019-05-28 10:57:03,991] ERROR Error while deleting segments for
groupby-stream-word_table-repartition-0 in dir
C:\Java\kafka_2.12-2.2.0\data\k-0 (kafka.server.LogDirFailureChannel)
java.nio.file.FileSystemException:
C:\Java\kafka_2.12-2.2.0\data\k-0\groupby-stream-word_table-repartition-0\.timeindex
->
C:\Java\kafka_2.12-2.2.0\data\k-0\groupby-stream-word_table-repartition-0\.timeindex.deleted:
Le processus ne peut pas accÚder au fichier car ce fichier est utilisÚ par un
autre processus.
at
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
at
sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
at java.nio.file.Files.move(Files.java:1395)
at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:805)
at kafka.log.AbstractIndex.renameTo(AbstractIndex.scala:205)
at kafka.log.LogSegment.changeFileSuffixes(LogSegment.scala:490)
at kafka.log.Log.asyncDeleteSegment(Log.scala:1924)
at kafka.log.Log.deleteSegment(Log.scala:1909)
at kafka.log.Log.$anonfun$deleteSegments$3(Log.scala:1455)
at kafka.log.Log.$anonfun$deleteSegments$3$adapted(Log.scala:1455)
at
scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62)
at
scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49)
at kafka.log.Log.$anonfun$deleteSegments$2(Log.scala:1455)
at
scala.runtime.java8.JFunction0$mcI$sp.apply(JFunction0$mcI$sp.java:23)
at kafka.log.Log.maybeHandleIOException(Log.scala:2013)
at kafka.log.Log.deleteSegments(Log.scala:1446)
at kafka.log.Log.deleteOldSegments(Log.scala:1441)
at kafka.log.Log.deleteLogStartOffsetBreachedSegments(Log.scala:1541)
at kafka.log.Log.deleteOldSegments(Log.scala:1509)
at kafka.log.LogManager.$anonfun$cleanupLogs$3(LogManager.scala:913)
at
kafka.log.LogManager.$anonfun$cleanupLogs$3$adapted(LogManager.scala:910)
at scala.collection.immutable.List.foreach(List.scala:392)
at kafka.log.LogManager.cleanupLogs(LogManager.scala:910)
at kafka.log.LogManager.$anonfun$startup$2(LogManager.scala:395)
at
kafka.utils.KafkaScheduler.$anonfun$schedule$2(KafkaScheduler.scala:114)
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.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
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)
Suppressed: java.nio.file.FileSystemException:
C:\Java\kafka_2.12-2.2.0\data\k-0\groupby-stream-word_table-repartition-0\.timeindex
->
C:\Java\kafka_2.12-2.2.0\data\k-0\groupby-stream-word_table-repartition-0\.timeindex.deleted:
Le processus ne peut pas accÚder au fichier car ce fichier est utilisÚ par un
autre processus.
at
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301)
at
sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
at java.nio.file.Files.move(Files.java:1395)
at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:802)
... 30 more{noformat}
> Error while deleting segments - The process cannot access the file because it
> is being used by another process
> --
>
> Key: KAFKA-6983
> URL: https://issues.
[jira] [Created] (KAFKA-8466) Remove 'jackson-module-scala' dependency (and replace it with some code)
Dejan Stojadinović created KAFKA-8466: - Summary: Remove 'jackson-module-scala' dependency (and replace it with some code) Key: KAFKA-8466 URL: https://issues.apache.org/jira/browse/KAFKA-8466 Project: Kafka Issue Type: Improvement Components: core Reporter: Dejan Stojadinović Assignee: Dejan Stojadinović *Prologue:* * [https://github.com/apache/kafka/pull/5454#issuecomment-497323889] * [https://github.com/apache/kafka/pull/5726/files#r289078080] *Rationale:* one dependency less is always a good thing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8517) A lot of WARN messages in kafka log "Received a PartitionLeaderEpoch assignment for an epoch < latestEpoch:
Jacek Żoch created KAFKA-8517:
-
Summary: A lot of WARN messages in kafka log "Received a
PartitionLeaderEpoch assignment for an epoch < latestEpoch:
Key: KAFKA-8517
URL: https://issues.apache.org/jira/browse/KAFKA-8517
Project: Kafka
Issue Type: Bug
Components: logging
Affects Versions: 0.11.0.1
Environment: PRD
Reporter: Jacek Żoch
We have 2.0 version but it was happening in version 0.11
In kafka log there is a lot of messages
"Received a PartitionLeaderEpoch assignment for an epoch < latestEpoch. This
implies messages have arrived out of order."
On 23.05 we had
Received a PartitionLeaderEpoch assignment for an epoch < latestEpoch. This
implies messages have arrived out of order. New: \{epoch:181,
offset:23562380995}, Current: \{epoch:362, offset10365488611} for Partition:
__consumer_offsets-30 (kafka.server.epoch.LeaderEpochFileCache)
Currently we have
Received a PartitionLeaderEpoch assignment for an epoch < latestEpoch. This
implies messages have arrived out of order. New: \{epoch:199,
offset:24588072027}, Current: \{epoch:362, offset:10365488611} for Partition:
__consumer_offsets-30 (kafka.server.epoch.LeaderEpochFileCache)
I think kafka should either fix it "under the hood" or have information how to
fix it
There is no information, how dangerous is it and how to fix it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KAFKA-3288) Update ZK dependency to 3.5.1 when it is marked as stable
[ https://issues.apache.org/jira/browse/KAFKA-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866761#comment-16866761 ] Gérald Quintana commented on KAFKA-3288: Zookeeper 3.5.5 is marked as stable > Update ZK dependency to 3.5.1 when it is marked as stable > - > > Key: KAFKA-3288 > URL: https://issues.apache.org/jira/browse/KAFKA-3288 > Project: Kafka > Issue Type: Sub-task >Reporter: Ashish Singh >Assignee: Ashish Singh >Priority: Major > > When a stable version of ZK 3.5.1+ is released, update Kafka's ZK dependency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-3287) Add over-wire encryption support between KAFKA and ZK
[ https://issues.apache.org/jira/browse/KAFKA-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866772#comment-16866772 ] Gérald Quintana commented on KAFKA-3287: This means adding Zookeeper client SSL support in Kafka Server and also in Kafka tooling like kafka-topics.sh, kafka-acls.sh, kafka-configs.sh... > Add over-wire encryption support between KAFKA and ZK > - > > Key: KAFKA-3287 > URL: https://issues.apache.org/jira/browse/KAFKA-3287 > Project: Kafka > Issue Type: Improvement >Reporter: Ashish Singh >Assignee: Ashish Singh >Priority: Major > > ZOOKEEPER-2125 added support for SSL. After Kafka upgrades ZK's dependency to > 3.5.1+ or 3.6.0+, SSL support between kafka broker and zk can be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-8568) MirrorMaker 2.0 resource leak
Péter Gergő Barna created KAFKA-8568:
Summary: MirrorMaker 2.0 resource leak
Key: KAFKA-8568
URL: https://issues.apache.org/jira/browse/KAFKA-8568
Project: Kafka
Issue Type: Bug
Components: KafkaConnect, mirrormaker
Affects Versions: 2.2.2
Reporter: Péter Gergő Barna
This issue produced by the branch KIP-382 (I am not sure which version is
affected by that)
While MirrorMaker 2.0 is running, the following command returns a number that
is getting larger and larger.
{noformat}
lsof -p | grep ESTABLISHED | wc -l{noformat}
In the error log, NullPointers pops up from the MirrorSourceTask.cleanup,
because either the consumer or the producer is null when the cleanup method
tries to close it.
{noformat}
Exception in thread "Thread-790" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
at java.lang.Thread.run(Thread.java:748)
Exception in thread "Thread-792" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
at java.lang.Thread.run(Thread.java:748)
Exception in thread "Thread-791" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:116)
at java.lang.Thread.run(Thread.java:748)
Exception in thread "Thread-793" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
at java.lang.Thread.run(Thread.java:748){noformat}
When the number of the established connections (returned by lsof) reaches a
certain limit, new exceptions start to pop up in the logs: Too many open files
{noformat}
[2019-06-19 12:56:43,949] ERROR WorkerSourceTask{id=MirrorHeartbeatConnector-0}
failed to send record to heartbeats: {}
(org.apache.kafka.connect.runtime.WorkerSourceTask)
org.apache.kafka.common.errors.SaslAuthenticationException: An error:
(java.security.PrivilegedActionException: javax.security.sasl.SaslException:
GSS initiate failed [Caused by
GSSException: No valid credentials provided (Mechanism level: Too many open
files)]) occurred when evaluating SASL token received from the Kafka Broker.
Kafka Client will go to A
UTHENTICATION_FAILED state.
Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
GSSException: No valid credentials provided (Mechanism level: Too many open
files)]
at
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.lambda$createSaslToken$1(SaslClientAuthenticator.java:461)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.createSaslToken(SaslClientAuthenticator.java:461)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendSaslClientToken(SaslClientAuthenticator.java:370)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendInitialToken(SaslClientAuthenticator.java:290)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.authenticate(SaslClientAuthenticator.java:230)
at
org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:173)
at
org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:536)
at org.apache.kafka.common.network.Selector.poll(Selector.java:472)
at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:535)
at
org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:311)
at
org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:235)
at java.lang.Thread.run(Thread.java:748)
Caused by: GSSException: No valid credentials provided (Mechanism level: Too
many open files)
at
sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:775)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:192)
... 14 more
Caused by: java.net.SocketException: Too many open files
at java.net.Socket.createImpl(Socket.java:460)
at java.net.Socket.connect(Socket.java:587)
at sun.security.krb5.internal.TCPClient.(NetClient.java:63)
at sun.security.krb5.internal.NetClient.getInstance(NetClient.java:43)
at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:393)
at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:364)
at java.secur
[jira] [Updated] (KAFKA-8568) MirrorMaker 2.0 resource leak
[
https://issues.apache.org/jira/browse/KAFKA-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Péter Gergő Barna updated KAFKA-8568:
-
Description:
This issue produced by the branch KIP-382 (I am not sure which version is
affected by that branch).
While MirrorMaker 2.0 is running, the following command returns a number that
is getting larger and larger.
{noformat}
lsof -p | grep ESTABLISHED | wc -l{noformat}
Meanwhile, in the error log, NullPointers pop up from the
MirrorSourceTask.cleanup, because either the consumer or the producer is null
when the cleanup method tries to close them.
{noformat}
Exception in thread "Thread-790" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
at java.lang.Thread.run(Thread.java:748)
Exception in thread "Thread-792" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
at java.lang.Thread.run(Thread.java:748)
Exception in thread "Thread-791" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:116)
at java.lang.Thread.run(Thread.java:748)
Exception in thread "Thread-793" java.lang.NullPointerException
at
org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
at java.lang.Thread.run(Thread.java:748){noformat}
When the number of the established connections (returned by lsof) reaches a
certain limit, new exceptions start to pop up in the logs: Too many open files
{noformat}
[2019-06-19 12:56:43,949] ERROR WorkerSourceTask{id=MirrorHeartbeatConnector-0}
failed to send record to heartbeats: {}
(org.apache.kafka.connect.runtime.WorkerSourceTask)
org.apache.kafka.common.errors.SaslAuthenticationException: An error:
(java.security.PrivilegedActionException: javax.security.sasl.SaslException:
GSS initiate failed [Caused by
GSSException: No valid credentials provided (Mechanism level: Too many open
files)]) occurred when evaluating SASL token received from the Kafka Broker.
Kafka Client will go to A
UTHENTICATION_FAILED state.
Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
GSSException: No valid credentials provided (Mechanism level: Too many open
files)]
at
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.lambda$createSaslToken$1(SaslClientAuthenticator.java:461)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.createSaslToken(SaslClientAuthenticator.java:461)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendSaslClientToken(SaslClientAuthenticator.java:370)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendInitialToken(SaslClientAuthenticator.java:290)
at
org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.authenticate(SaslClientAuthenticator.java:230)
at
org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:173)
at
org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:536)
at org.apache.kafka.common.network.Selector.poll(Selector.java:472)
at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:535)
at
org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:311)
at
org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:235)
at java.lang.Thread.run(Thread.java:748)
Caused by: GSSException: No valid credentials provided (Mechanism level: Too
many open files)
at
sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:775)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:192)
... 14 more
Caused by: java.net.SocketException: Too many open files
at java.net.Socket.createImpl(Socket.java:460)
at java.net.Socket.connect(Socket.java:587)
at sun.security.krb5.internal.TCPClient.(NetClient.java:63)
at sun.security.krb5.internal.NetClient.getInstance(NetClient.java:43)
at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:393)
at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:364)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.krb5.KdcComm.send(KdcComm.java:348)
at sun.security.krb5.KdcComm.sendIfPossible(KdcCom
[jira] [Commented] (KAFKA-8568) MirrorMaker 2.0 resource leak
[
https://issues.apache.org/jira/browse/KAFKA-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867719#comment-16867719
]
Péter Gergő Barna commented on KAFKA-8568:
--
tried to add null checks, it made the NullpointerExceptions go away, but the
leakage remained
{noformat}
private void cleanup() {
lock.lock();
try {
if (consumer != null){
consumer.close();
} else {
log.warn("Consumer was null in MirrorSourceTask cleanup");
}
// re-use the poll-timeout to approximate round-trip time
if (!outstandingOffsetSyncs.tryAcquire(MAX_OUTSTANDING_OFFSET_SYNCS, 2
* pollTimeout.toMillis(),
TimeUnit.MILLISECONDS)) {
log.warn("Timed out waiting for outstanding offset syncs.");
}
if (offsetProducer != null) {
offsetProducer.close();
} else {
log.warn("OffsetProducer was null in MirrorSourceTask cleanup");
}
} catch (InterruptedException e) {
log.info("Interrupted waiting for outstanding offset syncs.");
} finally {
lock.unlock();
}
}
{noformat}
> MirrorMaker 2.0 resource leak
> -
>
> Key: KAFKA-8568
> URL: https://issues.apache.org/jira/browse/KAFKA-8568
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect, mirrormaker
>Affects Versions: 2.2.2
>Reporter: Péter Gergő Barna
>Priority: Major
>
> This issue produced by the branch KIP-382 (I am not sure which version is
> affected by that branch).
> While MirrorMaker 2.0 is running, the following command returns a number that
> is getting larger and larger.
>
> {noformat}
> lsof -p | grep ESTABLISHED | wc -l{noformat}
>
> Meanwhile, in the error log, NullPointers pop up from the
> MirrorSourceTask.cleanup, because either the consumer or the producer is null
> when the cleanup method tries to close them.
>
> {noformat}
> Exception in thread "Thread-790" java.lang.NullPointerException
> at
> org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Exception in thread "Thread-792" java.lang.NullPointerException
> at
> org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Exception in thread "Thread-791" java.lang.NullPointerException
> at
> org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:116)
> at java.lang.Thread.run(Thread.java:748)
> Exception in thread "Thread-793" java.lang.NullPointerException
> at
> org.apache.kafka.connect.mirror.MirrorSourceTask.cleanup(MirrorSourceTask.java:110)
> at java.lang.Thread.run(Thread.java:748){noformat}
> When the number of the established connections (returned by lsof) reaches a
> certain limit, new exceptions start to pop up in the logs: Too many open files
> {noformat}
> [2019-06-19 12:56:43,949] ERROR
> WorkerSourceTask{id=MirrorHeartbeatConnector-0} failed to send record to
> heartbeats: {} (org.apache.kafka.connect.runtime.WorkerSourceTask)
> org.apache.kafka.common.errors.SaslAuthenticationException: An error:
> (java.security.PrivilegedActionException: javax.security.sasl.SaslException:
> GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Too many open
> files)]) occurred when evaluating SASL token received from the Kafka Broker.
> Kafka Client will go to A
> UTHENTICATION_FAILED state.
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Too many open
> files)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
> at
> org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.lambda$createSaslToken$1(SaslClientAuthenticator.java:461)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.createSaslToken(SaslClientAuthenticator.java:461)
> at
> org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendSaslClientToken(SaslClientAuthenticator.java:370)
> at
> org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendInitialToken(SaslClientAuthenticator.java:290)
> at
> org.apache.kafka.co
[jira] [Commented] (KAFKA-5115) Use bootstrap.servers to refresh metadata
[ https://issues.apache.org/jira/browse/KAFKA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872476#comment-16872476 ] Sönke Liebau commented on KAFKA-5115: - Hi [~MiniMizer], we've just discussed this today and while the change itself would be fairly simple, I believe there are a lot of areas that would need investigating / testing before this could be recommended for a production deployment. Specifically everything around transactions and idempotent producers seem to me to be worth a dedicated look. On the consumer side, the immediate concern I think is offsets, stored offsets might not create issues (but may also not work) - but anything cached inside the Fetcher cause havoc.. Bottom line: it is a good idea that I'd fully support, but probably needs more work than is immediately apparent. > Use bootstrap.servers to refresh metadata > - > > Key: KAFKA-5115 > URL: https://issues.apache.org/jira/browse/KAFKA-5115 > Project: Kafka > Issue Type: Improvement >Affects Versions: 0.10.2.0 >Reporter: Dan >Priority: Major > > Currently, it seems that bootstrap.servers list is used only when the > producer starts, to discover the cluster, and subsequent metadata refreshes > go to the discovered brokers directly. > We would like to use the bootstrap.servers list for metadata refresh to > support a failover mechanism by providing a VIP which can dynamically > redirect requests to a secondary Kafka cluster if the primary is down. > Consider the following use case, where "kafka-cluster.local" is a VIP on a > load balancer with priority server pools that point to two different Kafka > clusters (so when all servers of cluster #1 are down, it automatically > redirects to servers from cluster #2). > bootstrap.servers: kafka-cluster.local:9092 > 1) Producer starts, connects to kafka-cluster.local and discovers all servers > from cluster #1 > 2) Producer starts producing to cluster #1 > 3) cluster #1 goes down > 4) Producer detects the failure, refreshes metadata from kafka-cluster.local > (which now returns nodes from cluster #2) > 5) Producer starts producing to cluster #2 > 6) cluster #1 is brought back online, and kafka-cluster.local now points to > it again > In the current state, it seems that the producer will never revert to cluster > #1 because it continues to refresh its metadata from the brokers of cluster > #2, even though kafka-cluster.local no longer points to that cluster. > If we could force the metadata refresh to happen against > "kafka-cluster.local", it would enable automatic failover and failback > between the clusters. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-7077) KIP-318: Make Kafka Connect Source idempotent
[ https://issues.apache.org/jira/browse/KAFKA-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873440#comment-16873440 ] Jose A. Iñigo commented on KAFKA-7077: -- Hi [~stephane.maa...@gmail.com], are there any plans to address this in the near future? > KIP-318: Make Kafka Connect Source idempotent > - > > Key: KAFKA-7077 > URL: https://issues.apache.org/jira/browse/KAFKA-7077 > Project: Kafka > Issue Type: Improvement > Components: KafkaConnect >Affects Versions: 2.0.0 >Reporter: Stephane Maarek >Assignee: Stephane Maarek >Priority: Major > > KIP Link: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-318%3A+Make+Kafka+Connect+Source+idempotent -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-8624) 这边是服务端的kafka，版本是 kafka_2.11-1.0.0.2，当客户端向主题发送消息的时候抛出如下异常，客户端跟服务端的版本不一致吗？
[
https://issues.apache.org/jira/browse/KAFKA-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877560#comment-16877560
]
许晋瑞 commented on KAFKA-8624:
Could you provide the versions of client and server that you use? Maybe I can
offer some help.
> 这边是服务端的kafka，版本是 kafka_2.11-1.0.0.2，当客户端向主题发送消息的时候抛出如下异常，客户端跟服务端的版本不一致吗？
>
>
> Key: KAFKA-8624
> URL: https://issues.apache.org/jira/browse/KAFKA-8624
> Project: Kafka
> Issue Type: Bug
> Components: log
>Affects Versions: 1.0.0
>Reporter: CHARELS
>Priority: Major
> Labels: pull-request-available
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> ERROR [KafkaApi-1004] Error when handling request
> \{replica_id=-1,max_wait_time=1,min_bytes=0,topics=[{topic=ETE,partitions=[{partition=3,fetch_offset=119224671,max_bytes=1048576}]}]}
> (kafka.server.KafkaApis)
> java.lang.IllegalArgumentException: Magic v0 does not support record headers
> at
> org.apache.kafka.common.record.MemoryRecordsBuilder.appendWithOffset(MemoryRecordsBuilder.java:403)
> at
> org.apache.kafka.common.record.MemoryRecordsBuilder.append(MemoryRecordsBuilder.java:586)
> at
> org.apache.kafka.common.record.AbstractRecords.convertRecordBatch(AbstractRecords.java:134)
> at
> org.apache.kafka.common.record.AbstractRecords.downConvert(AbstractRecords.java:109)
> at
> org.apache.kafka.common.record.FileRecords.downConvert(FileRecords.java:253)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$convertedPartitionData$1$1$$anonfun$apply$4.apply(KafkaApis.scala:519)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$convertedPartitionData$1$1$$anonfun$apply$4.apply(KafkaApis.scala:517)
> at scala.Option.map(Option.scala:146)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$convertedPartitionData$1$1.apply(KafkaApis.scala:517)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$convertedPartitionData$1$1.apply(KafkaApis.scala:507)
> at scala.Option.flatMap(Option.scala:171)
> at
> kafka.server.KafkaApis.kafka$server$KafkaApis$$convertedPartitionData$1(KafkaApis.scala:507)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$createResponse$2$1.apply(KafkaApis.scala:555)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$createResponse$2$1.apply(KafkaApis.scala:554)
> at scala.collection.Iterator$class.foreach(Iterator.scala:891)
> at scala.collection.AbstractIterator.foreach(Iterator.scala:1334)
> at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
> at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
> at
> kafka.server.KafkaApis.kafka$server$KafkaApis$$createResponse$2(KafkaApis.scala:554)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$fetchResponseCallback$1$1.apply(KafkaApis.scala:568)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$fetchResponseCallback$1$1.apply(KafkaApis.scala:568)
> at
> kafka.server.KafkaApis$$anonfun$sendResponseMaybeThrottle$1.apply$mcVI$sp(KafkaApis.scala:2033)
> at
> kafka.server.ClientRequestQuotaManager.maybeRecordAndThrottle(ClientRequestQuotaManager.scala:54)
> at kafka.server.KafkaApis.sendResponseMaybeThrottle(KafkaApis.scala:2032)
> at
> kafka.server.KafkaApis.kafka$server$KafkaApis$$fetchResponseCallback$1(KafkaApis.scala:568)
> at
> kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$processResponseCallback$1$1.apply$mcVI$sp(KafkaApis.scala:587)
> at
> kafka.server.ClientQuotaManager.maybeRecordAndThrottle(ClientQuotaManager.scala:176)
> at
> kafka.server.KafkaApis.kafka$server$KafkaApis$$processResponseCallback$1(KafkaApis.scala:586)
> at
> kafka.server.KafkaApis$$anonfun$handleFetchRequest$3.apply(KafkaApis.scala:603)
> at
> kafka.server.KafkaApis$$anonfun$handleFetchRequest$3.apply(KafkaApis.scala:603)
> at kafka.server.ReplicaManager.fetchMessages(ReplicaManager.scala:820)
> at kafka.server.KafkaApis.handleFetchRequest(KafkaApis.scala:595)
> at kafka.server.KafkaApis.handle(KafkaApis.scala:99)
> at kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:65)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KAFKA-8659) SetSchemaMetadata SMT fails on records with null value and schema
Marc Löhe created KAFKA-8659:
Summary: SetSchemaMetadata SMT fails on records with null value
and schema
Key: KAFKA-8659
URL: https://issues.apache.org/jira/browse/KAFKA-8659
Project: Kafka
Issue Type: Bug
Components: KafkaConnect
Reporter: Marc Löhe
If you use the {{SetSchemaMetadata}} SMT with records for which the key or
value and corresponding schema are {{null}} (i.e. tombstone records from
[Debezium|[https://debezium.io/]), the transform will fail.
{code:java}
org.apache.kafka.connect.errors.ConnectException: Tolerance exceeded in error
handler
at
org.apache.kafka.connect.runtime.errors.RetryWithToleranceOperator.execAndHandleError(RetryWithToleranceOperator.java:178)
at
org.apache.kafka.connect.runtime.errors.RetryWithToleranceOperator.execute(RetryWithToleranceOperator.java:104)
at
org.apache.kafka.connect.runtime.TransformationChain.apply(TransformationChain.java:50)
at
org.apache.kafka.connect.runtime.WorkerSourceTask.sendRecords(WorkerSourceTask.java:293)
at
org.apache.kafka.connect.runtime.WorkerSourceTask.execute(WorkerSourceTask.java:229)
at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:175)
at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:219)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
Caused by: org.apache.kafka.connect.errors.DataException: Schema required for
[updating schema metadata]
at
org.apache.kafka.connect.transforms.util.Requirements.requireSchema(Requirements.java:31)
at
org.apache.kafka.connect.transforms.SetSchemaMetadata.apply(SetSchemaMetadata.java:67)
at
org.apache.kafka.connect.runtime.TransformationChain.lambda$apply$0(TransformationChain.java:50)
at
org.apache.kafka.connect.runtime.errors.RetryWithToleranceOperator.execAndRetry(RetryWithToleranceOperator.java:128)
at
org.apache.kafka.connect.runtime.errors.RetryWithToleranceOperator.execAndHandleError(RetryWithToleranceOperator.java:162)
... 11 more
{code}
I don't see any problem in passing those records as is in favor of failing and
will shortly add this in a PR.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (KAFKA-8660) Make ValueToKey SMT work only on a whitelist of topics
Marc Löhe created KAFKA-8660: Summary: Make ValueToKey SMT work only on a whitelist of topics Key: KAFKA-8660 URL: https://issues.apache.org/jira/browse/KAFKA-8660 Project: Kafka Issue Type: Improvement Components: KafkaConnect Reporter: Marc Löhe For source connectors that publish on multiple topics it is essential to be able to configure transforms to be active only for certain topics. I'll add a PR to implement this on the example of the ValueToKey SMT. I'm also interested if this would make sense to add as a configurable option to all packaged SMTs or even as a capability for SMTs in general. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (KAFKA-8660) Make ValueToKey SMT work only on a whitelist of topics
[ https://issues.apache.org/jira/browse/KAFKA-8660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Löhe updated KAFKA-8660: - Description: For source connectors that publish on multiple topics it is essential to be able to configure transforms to be active only for certain topics. I'll add a PR to implement this on the example of the ValueToKey SMT. I'm also interested in opionions if this would make sense to add as a configurable option to all packaged SMTs or even as a capability for SMTs in general. was: For source connectors that publish on multiple topics it is essential to be able to configure transforms to be active only for certain topics. I'll add a PR to implement this on the example of the ValueToKey SMT. I'm also interested if this would make sense to add as a configurable option to all packaged SMTs or even as a capability for SMTs in general. > Make ValueToKey SMT work only on a whitelist of topics > -- > > Key: KAFKA-8660 > URL: https://issues.apache.org/jira/browse/KAFKA-8660 > Project: Kafka > Issue Type: Improvement > Components: KafkaConnect >Reporter: Marc Löhe >Priority: Minor > > For source connectors that publish on multiple topics it is essential to be > able to configure transforms to be active only for certain topics. I'll add a > PR to implement this on the example of the ValueToKey SMT. > I'm also interested in opionions if this would make sense to add as a > configurable option to all packaged SMTs or even as a capability for SMTs in > general. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KAFKA-8679) kafka-topics.sh --describe with --zookeeper throws error when there is no topic
[
https://issues.apache.org/jira/browse/KAFKA-8679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887719#comment-16887719
]
Sönke Liebau commented on KAFKA-8679:
-
Hi [~weichu], this looks to me to be a duplicate of KAFKA-8670, you even
followed the trail to the same ticket as introducing this error.
Can you perhaps double check that ticket and confirm if this is indeed covered
by it?
> kafka-topics.sh --describe with --zookeeper throws error when there is no
> topic
> ---
>
> Key: KAFKA-8679
> URL: https://issues.apache.org/jira/browse/KAFKA-8679
> Project: Kafka
> Issue Type: Bug
>Reporter: Weichu Liu
>Priority: Minor
>
> h3. Step to Reproduce:
> First, start a Kafka server (2.2.0+), with no topic on it.
> Then run `kafka-topics.sh --describe --zookeeper ...:2181` to get topic
> details
> h3. Expected Behavior
> Expected Behavior should be the command prints nothing and return 0.
> h3. Actual Behavior
> The command throws an exception and exit with 1.
> {code}
> $ kafka_2.12-2.2.1/bin/kafka-topics.sh --describe --zookeeper localhost:2181
> Error while executing topic command : Topics in [] does not exist
> [2019-07-18 06:29:21,336] ERROR java.lang.IllegalArgumentException: Topics in
> [] does not exist
> at
> kafka.admin.TopicCommand$.kafka$admin$TopicCommand$$ensureTopicExists(TopicCommand.scala:416)
> at
> kafka.admin.TopicCommand$ZookeeperTopicService.describeTopic(TopicCommand.scala:332)
> at kafka.admin.TopicCommand$.main(TopicCommand.scala:66)
> at kafka.admin.TopicCommand.main(TopicCommand.scala)
> (kafka.admin.TopicCommand$)
> {code}
> h3. Others
> IIRC, the version before 2.2.0 did not throw exceptions.
> Also, {{--describing}} with {{--bootstrap-server}} will exit 0 and print
> nothing.
> Also {{--list}} with either {{--bootstrap-server}} and {{--zookeeper}} will
> also exit 0 and prints nothing.
> I did some quick search and seems this issue is introduced by
> https://issues.apache.org/jira/browse/KAFKA-7054. I didn't check which exact
> line caused the exception. Hope that will help.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (KAFKA-1016) Broker should limit purgatory size
[ https://issues.apache.org/jira/browse/KAFKA-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888768#comment-16888768 ] Sönke Liebau commented on KAFKA-1016: - Is this still relevant after the Purgatory redesign in KAFKA-1430 and KAFKA-1989 ? It seems to me that the improvements made there would at least alleviate the issue described here due to vast performance improvements, even if no hard limit is introduced (which I'm not sure we want to do, as this basically would mean limiting the number of consumers that we are willing to serve). > Broker should limit purgatory size > -- > > Key: KAFKA-1016 > URL: https://issues.apache.org/jira/browse/KAFKA-1016 > Project: Kafka > Issue Type: Bug > Components: purgatory >Affects Versions: 0.8.0 >Reporter: Chris Riccomini >Assignee: Joel Koshy >Priority: Major > > I recently ran into a case where a poorly configured Kafka consumer was able > to trigger out of memory exceptions in multiple Kafka brokers. The consumer > was configured to have a fetcher.max.wait of Int.MaxInt. > For low volume topics, this configuration causes the consumer to block for > frequently, and for long periods of time. [~junrao] informs me that the fetch > request will time out after the socket timeout is reached. In our case, this > was set to 30s. > With several thousand consumer threads, the fetch request purgatory got into > the 100,000-400,000 range, which we believe triggered the out of memory > exception. [~nehanarkhede] claims to have seem similar behavior in other high > volume clusters. > It kind of seems like a bad thing that a poorly configured consumer can > trigger out of memory exceptions in the broker. I was thinking maybe it makes > sense to have the broker try and protect itself from this situation. Here are > some potential solutions: > 1. Have a broker-side max wait config for fetch requests. > 2. Threshold the purgatory size, and either drop the oldest connections in > purgatory, or reject the newest fetch requests when purgatory is full. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KAFKA-822) Reassignment of partitions needs a cleanup
[ https://issues.apache.org/jira/browse/KAFKA-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888771#comment-16888771 ] Sönke Liebau commented on KAFKA-822: While not 100% sure how this looks in today's code, but I do believe that the /admin/reassign_partitons znode gets deleted after a finished reassignment at least (see for example KAFKA-6193). I'd be in favor of closing this due to no activity for more than 6 years. > Reassignment of partitions needs a cleanup > -- > > Key: KAFKA-822 > URL: https://issues.apache.org/jira/browse/KAFKA-822 > Project: Kafka > Issue Type: Bug > Components: controller, tools >Affects Versions: 0.8.0 >Reporter: Swapnil Ghike >Assignee: Swapnil Ghike >Priority: Major > Labels: bugs > > 1. This is probably a left-over from when the ReassignPartitionsCommand used > to be blocking: > Currently, for each partition that is reassigned, controller deletes the > /admin/reassign_partitions zk path, and populates it with a new list with the > reassigned partition removed from the original list. This is probably an > overkill, and we can delete the zk path completely once the reassignment of > all partitions has completed successfully or in error. > 2. It will help to clarify that there could be no replicas that have started > and are not in the ISR when KafkaController.onPartitionReassignment() is > called. > 3. We should batch the requests in > KafkaController.StopOldReplicasOfReassignedPartition() > 4. Update controllerContext.partitionReplicaAssignment only once in > KafkaController.updateAssignedReplicasForPartition(). > 5. Need to thoroughly test. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KAFKA-1234) All kafka-run-class.sh to source in user config file (to set env vars like KAFKA_OPTS)
[ https://issues.apache.org/jira/browse/KAFKA-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888782#comment-16888782 ] Sönke Liebau commented on KAFKA-1234: - I'm unsure what the "gospel" way of doing this is, but my personal belief is that tools that run Kafka as a service should allow for management of environment variables. Most prevalent these days is probably systemd, which makes this very easy. I have limited experience with Upstart but do believe this is possible, if somewhat awkward. For init.d scripts I have not really found an acceptable solution apart from sourcing an env file from the init.d script, but as Kafka does not include these you would have to create them yourself anyway, so sourcing something should not create any conflicts with updates etc. Relying on a file in the Kafka base dir bears the risk of losing this file during an update, depending on how that update is performed, so I'd prefer relying on external methods. > All kafka-run-class.sh to source in user config file (to set env vars like > KAFKA_OPTS) > -- > > Key: KAFKA-1234 > URL: https://issues.apache.org/jira/browse/KAFKA-1234 > Project: Kafka > Issue Type: Improvement > Components: config >Affects Versions: 0.8.0 >Reporter: Alex Gray >Priority: Trivial > Attachments: patch.txt > > > We are using the distributed version of kafka: > http://apache.mirrors.lucidnetworks.net/kafka/0.8.0/kafka_2.8.0-0.8.0.tar.gz > And we would like to set some environment variables, particularly KAFKA_OPTS > when the kafka service starts. > In other words, when someone does a "sudo service kafka start" we would like > to set some environment variables. > We cannot do this *without* modifying either /etc/init.d/kafka or > bin/kafka-run-class.sh, and we don't want to modify files that we don't own. > The solution is to have kafka source in a user specific file that may have > these environment variables set. > I'm attaching the patch file to show you what I mean. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KAFKA-1099) StopReplicaRequest and StopReplicaResponse should also carry the replica ids
[ https://issues.apache.org/jira/browse/KAFKA-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888786#comment-16888786 ] Sönke Liebau commented on KAFKA-1099: - Pretty sure this information has not been included in the requests until now (at least I cannot find it in the code), but as this is now 6 years old, is this still relevant or has become obsolete by different changes in the meantime? > StopReplicaRequest and StopReplicaResponse should also carry the replica ids > > > Key: KAFKA-1099 > URL: https://issues.apache.org/jira/browse/KAFKA-1099 > Project: Kafka > Issue Type: Bug > Components: controller >Affects Versions: 0.8.1 >Reporter: Neha Narkhede >Assignee: Neha Narkhede >Priority: Major > > The stop replica request and response only contain a list of partitions for > which a replica should be moved to offline/nonexistent state. But the replica > id information is implicit in the network layer as the receiving broker. This > complicates stop replica response handling on the controller. This blocks the > right fix for KAFKA-1097 since it requires invoking callback for processing a > StopReplicaResponse and it requires to know the replica id from the > StopReplicaResponse. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (KAFKA-1111) Broker prematurely accepts TopicMetadataRequests on startup
[
https://issues.apache.org/jira/browse/KAFKA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888789#comment-16888789
]
Sönke Liebau commented on KAFKA-:
-
I've not tested this, but there has been some work around TopicMetadataRequests
creating topics. Most notably KAFKA-5291 which is at least related to this, but
certainly doesn't fix it.
Looking at the date on this though, is this still an issue or can we close this?
> Broker prematurely accepts TopicMetadataRequests on startup
> ---
>
> Key: KAFKA-
> URL: https://issues.apache.org/jira/browse/KAFKA-
> Project: Kafka
> Issue Type: Bug
>Reporter: Jason Rosenberg
>Assignee: Neha Narkhede
>Priority: Major
>
> I have an issue where on startup, the broker starts accepting
> TopicMetadataRequests before it has had metadata sync'd from the controller.
> This results in a bunch of log entries that look like this:
> 013-11-01 03:26:01,577 INFO [kafka-request-handler-0] admin.AdminUtils$ -
> Topic creation { "partitions":{ "0":[ 9, 10 ] }, "version":1 }
> 2013-11-01 03:26:07,767 INFO [kafka-request-handler-1] admin.AdminUtils$ -
> Topic creation { "partitions":{ "0":[ 9, 11 ] }, "version":1 }
> 2013-11-01 03:26:07,823 INFO [kafka-request-handler-1] admin.AdminUtils$ -
> Topic creation { "partitions":{ "0":[ 10, 11 ] }, "version":1 }
> 2013-11-01 03:26:11,183 INFO [kafka-request-handler-2] admin.AdminUtils$ -
> Topic creation { "partitions":{ "0":[ 10, 11 ] }, "version":1 }
> From an email thread, Neha remarks:
> Before a broker receives the first
> LeaderAndIsrRequest/UpdateMetadataRequest, it is technically not ready to
> start serving any request. But it still ends up serving
> TopicMetadataRequest which can re-create topics accidentally. It shouldn't
> succeed, but this is still a problem.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (KAFKA-8698) ListOffsets Response protocol documentation
Fábio Silva created KAFKA-8698:
--
Summary: ListOffsets Response protocol documentation
Key: KAFKA-8698
URL: https://issues.apache.org/jira/browse/KAFKA-8698
Project: Kafka
Issue Type: Bug
Components: documentation
Reporter: Fábio Silva
The documentation of ListOffsets Response (Version: 0) appears to have an error
on offsets field name, suffixed with `'`.
{code:java}
[offsets']{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (KAFKA-9308) Misses SAN after certificate creation
[
https://issues.apache.org/jira/browse/KAFKA-9308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998337#comment-16998337
]
Sönke Liebau commented on KAFKA-9308:
-
I believe this is due to the fact that the x509 module of openssl only adds
extensions to signed certificates that are passed via the -extfile parameter.
Any extensions that are requested in the CSR are ignored.
For this to work you'd need to create a proper CA with signing profiles like
shown here: https://stackoverflow.com/a/21340898/7183757
Might make sense to update the docs for this.
> Misses SAN after certificate creation
> -
>
> Key: KAFKA-9308
> URL: https://issues.apache.org/jira/browse/KAFKA-9308
> Project: Kafka
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.3.1
>Reporter: Agostino Sarubbo
>Priority: Minor
>
> Hello,
> I followed the documentation to use kafka with ssl, however the entire
> 'procedure' loses at the end the specified SAN.
> To test, run (after the first keytool command and after the latest):
>
> {code:java}
> keytool -list -v -keystore server.keystore.jks
> {code}
> Reference:
> [http://kafka.apache.org/documentation.html#security_ssl]
>
> {code:java}
> #!/bin/bash
> #Step 1
> keytool -keystore server.keystore.jks -alias localhost -validity 365 -keyalg
> RSA -genkey -ext SAN=DNS:test.test.com
> #Step 2
> openssl req -new -x509 -keyout ca-key -out ca-cert -days 365
> keytool -keystore server.truststore.jks -alias CARoot -import -file ca-cert
> keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert
> #Step 3
> keytool -keystore server.keystore.jks -alias localhost -certreq -file
> cert-file
> openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed
> -days 365 -CAcreateserial -passin pass:test1234
> keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert
> keytool -keystore server.keystore.jks -alias localhost -import -file
> cert-signed
> {code}
>
> In the detail, the SAN is losed after:
> {code:java}
> keytool -keystore server.keystore.jks -alias localhost -import -file
> cert-signed
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (KAFKA-9311) Jumbled table content for broker config doc
[ https://issues.apache.org/jira/browse/KAFKA-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau resolved KAFKA-9311. - Resolution: Not A Problem This is not an error but was a conscious change in KAFKA-8474 to improve the readability of that section. > Jumbled table content for broker config doc > --- > > Key: KAFKA-9311 > URL: https://issues.apache.org/jira/browse/KAFKA-9311 > Project: Kafka > Issue Type: Bug > Components: documentation >Affects Versions: 2.4.0 >Reporter: Joel Hamill >Priority: Major > Attachments: image-2019-12-17-14-48-19-927.png, > image-2019-12-17-14-48-50-800.png > > > The current version of the broker configs has broken table formatting: > [https://kafka.apache.org/documentation/#brokerconfigs] > !image-2019-12-17-14-48-50-800.png! > Previous version: > [https://kafka.apache.org/23/documentation/#brokerconfigs] > !image-2019-12-17-14-48-19-927.png! > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (KAFKA-9376) Plugin class loader not found using MM2
Sinóros-Szabó Péter created KAFKA-9376:
--
Summary: Plugin class loader not found using MM2
Key: KAFKA-9376
URL: https://issues.apache.org/jira/browse/KAFKA-9376
Project: Kafka
Issue Type: Bug
Components: mirrormaker
Affects Versions: 2.4.0
Reporter: Sinóros-Szabó Péter
I am using MM2 (release 2.4.0 with scala 2.12) I geta bunch of classloader
errors. MM2 seems to be working, but I do not know if all of it components are
working as expected as this is the first time I use MM2.
I run MM2 with the following command:
{code:java}
./bin/connect-mirror-maker.sh config/connect-mirror-maker.properties
{code}
Errors are:
{code:java}
[2020-01-07 15:06:17,892] ERROR Plugin class loader for connector:
'org.apache.kafka.connect.mirror.MirrorHeartbeatConnector' was not found.
Returning:
org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader@6ebf0f36
(org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader:165)
[2020-01-07 15:06:17,889] ERROR Plugin class loader for connector:
'org.apache.kafka.connect.mirror.MirrorHeartbeatConnector' was not found.
Returning:
org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader@6ebf0f36
(org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader:165)
[2020-01-07 15:06:17,904] INFO ConnectorConfig values:
config.action.reload = restart
connector.class = org.apache.kafka.connect.mirror.MirrorHeartbeatConnector
errors.log.enable = false
errors.log.include.messages = false
errors.retry.delay.max.ms = 6
errors.retry.timeout = 0
errors.tolerance = none
header.converter = null
key.converter = null
name = MirrorHeartbeatConnector
tasks.max = 1
transforms = []
value.converter = null
(org.apache.kafka.connect.runtime.ConnectorConfig:347)
[2020-01-07 15:06:17,904] INFO EnrichedConnectorConfig values:
config.action.reload = restart
connector.class = org.apache.kafka.connect.mirror.MirrorHeartbeatConnector
errors.log.enable = false
errors.log.include.messages = false
errors.retry.delay.max.ms = 6
errors.retry.timeout = 0
errors.tolerance = none
header.converter = null
key.converter = null
name = MirrorHeartbeatConnector
tasks.max = 1
transforms = []
value.converter = null
(org.apache.kafka.connect.runtime.ConnectorConfig$EnrichedConnectorConfig:347)
[2020-01-07 15:06:17,905] INFO TaskConfig values:
task.class = class org.apache.kafka.connect.mirror.MirrorHeartbeatTask
(org.apache.kafka.connect.runtime.TaskConfig:347)
[2020-01-07 15:06:17,905] INFO Instantiated task MirrorHeartbeatConnector-0
with version 1 of type org.apache.kafka.connect.mirror.MirrorHeartbeatTask
(org.apache.kafka.connect.runtime.Worker:434){code}
After a while, these errors are not logged any more.
Config is:
{code:java}
clusters = eucmain, euwbackup
eucmain.bootstrap.servers = kafka1:9092,kafka2:9092
euwbackup.bootstrap.servers = 172.30.197.203:9092,172.30.213.104:9092
eucmain->euwbackup.enabled = true
eucmain->euwbackup.topics = .*
eucmain->euwbackup.topics.blacklist = ^(kafka|kmf|__|pricing).*
eucmain->euwbackup.rename.topics = false
rename.topics = false
eucmain->euwbackup.sync.topic.acls.enabled = false
sync.topic.acls.enabled = false{code}
Using OpenJDK 8 or 11, I get the same error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-9397) Deprecate Direct Zookeeper access in Kafka Administrative Tools
[ https://issues.apache.org/jira/browse/KAFKA-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013151#comment-17013151 ] Gérald Quintana commented on KAFKA-9397: kafka-acl.sh doesn''t have --zookeeper argument, but --authorizer-property zookeeper.connect is the same at the end > Deprecate Direct Zookeeper access in Kafka Administrative Tools > --- > > Key: KAFKA-9397 > URL: https://issues.apache.org/jira/browse/KAFKA-9397 > Project: Kafka > Issue Type: Improvement > Components: tools >Affects Versions: 2.5.0 >Reporter: Colin McCabe >Assignee: Colin McCabe >Priority: Major > Fix For: 2.5.0 > > > KIP-555: Deprecate Direct Zookeeper access in Kafka Administrative Tools -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-9308) Misses SAN after certificate creation
[
https://issues.apache.org/jira/browse/KAFKA-9308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014989#comment-17014989
]
Sönke Liebau commented on KAFKA-9308:
-
Hi [~ago], thanks for the update. Would you be interested in creating a pull
request to update the documentation?
Regarding your second question, that is a bit hard to diagnose without further
detail, does it give any reason why the handshake failed?
> Misses SAN after certificate creation
> -
>
> Key: KAFKA-9308
> URL: https://issues.apache.org/jira/browse/KAFKA-9308
> Project: Kafka
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.3.1
>Reporter: Agostino Sarubbo
>Priority: Minor
>
> Hello,
> I followed the documentation to use kafka with ssl, however the entire
> 'procedure' loses at the end the specified SAN.
> To test, run (after the first keytool command and after the latest):
>
> {code:java}
> keytool -list -v -keystore server.keystore.jks
> {code}
> Reference:
> [http://kafka.apache.org/documentation.html#security_ssl]
>
> {code:java}
> #!/bin/bash
> #Step 1
> keytool -keystore server.keystore.jks -alias localhost -validity 365 -keyalg
> RSA -genkey -ext SAN=DNS:test.test.com
> #Step 2
> openssl req -new -x509 -keyout ca-key -out ca-cert -days 365
> keytool -keystore server.truststore.jks -alias CARoot -import -file ca-cert
> keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert
> #Step 3
> keytool -keystore server.keystore.jks -alias localhost -certreq -file
> cert-file
> openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed
> -days 365 -CAcreateserial -passin pass:test1234
> keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert
> keytool -keystore server.keystore.jks -alias localhost -import -file
> cert-signed
> {code}
>
> In the detail, the SAN is losed after:
> {code:java}
> keytool -keystore server.keystore.jks -alias localhost -import -file
> cert-signed
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
Sönke Liebau created KAFKA-9423: --- Summary: Refine layout of configuration options on website and make individual settings directly linkable Key: KAFKA-9423 URL: https://issues.apache.org/jira/browse/KAFKA-9423 Project: Kafka Issue Type: Improvement Components: documentation Reporter: Sönke Liebau Attachments: image-2020-01-14-11-17-55-277.png, image-2020-01-14-11-18-12-190.png, image-2020-01-14-11-18-24-939.png, image-2020-01-14-11-18-36-825.png KAKFA-8474 changed the layout of configuration options on the website from a table which over time ran out of horizontal space to a list. This vastly improved readability but is not yet ideal. Further discussion was had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. This ticket is to move that discussion to a separate thread and make it more visible to other people and to give subsequent PRs a home. Currently proposed options are listed below. Option 1: !image-2020-01-14-11-17-55-277.png|thumbnail! Option 2: !image-2020-01-14-11-18-12-190.png|thumbnail! Option 3: !image-2020-01-14-11-18-24-939.png|thumbnail! Option 4: !image-2020-01-14-11-18-36-825.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau reassigned KAFKA-9423: --- Assignee: Sönke Liebau > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > Attachments: image-2020-01-14-11-17-55-277.png, > image-2020-01-14-11-18-12-190.png, image-2020-01-14-11-18-24-939.png, > image-2020-01-14-11-18-36-825.png > > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are listed below. > Option 1: > !image-2020-01-14-11-17-55-277.png|thumbnail! > Option 2: > !image-2020-01-14-11-18-12-190.png|thumbnail! > Option 3: > !image-2020-01-14-11-18-24-939.png|thumbnail! > Option 4: > !image-2020-01-14-11-18-36-825.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau updated KAFKA-9423: Attachment: (was: image-2020-01-14-11-17-55-277.png) > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau updated KAFKA-9423: Description: KAKFA-8474 changed the layout of configuration options on the website from a table which over time ran out of horizontal space to a list. This vastly improved readability but is not yet ideal. Further discussion was had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. This ticket is to move that discussion to a separate thread and make it more visible to other people and to give subsequent PRs a home. Currently proposed options are attached to this issue. was: KAKFA-8474 changed the layout of configuration options on the website from a table which over time ran out of horizontal space to a list. This vastly improved readability but is not yet ideal. Further discussion was had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. This ticket is to move that discussion to a separate thread and make it more visible to other people and to give subsequent PRs a home. Currently proposed options are listed below. Option 1: !image-2020-01-14-11-17-55-277.png|thumbnail! Option 2: !image-2020-01-14-11-18-12-190.png|thumbnail! Option 3: !image-2020-01-14-11-18-24-939.png|thumbnail! Option 4: !image-2020-01-14-11-18-36-825.png|thumbnail! > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau updated KAFKA-9423: Attachment: (was: image-2020-01-14-11-18-12-190.png) > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau updated KAFKA-9423: Attachment: (was: image-2020-01-14-11-18-24-939.png) > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau updated KAFKA-9423: Attachment: (was: image-2020-01-14-11-18-36-825.png) > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau updated KAFKA-9423: Attachment: option4.png option3.png option2.png option1.png > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > Attachments: option1.png, option2.png, option3.png, option4.png > > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014995#comment-17014995 ] Sönke Liebau commented on KAFKA-9423: - Personally I am in favor of one of the options that list options vertically (1 & 3). If we have the specifications on one line, we risk running out of horizontal space again for example if a setting has a very long default value. > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > Attachments: option1.png, option2.png, option3.png, option4.png > > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015040#comment-17015040 ] Sönke Liebau commented on KAFKA-9423: - I've taken the liberty of creating a pull request with option 3 ping [~hachikuji] & [~mimaison] if you find a bit of time for a review. > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > Attachments: option1.png, option2.png, option3.png, option4.png > > > KAKFA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau updated KAFKA-9423: Description: KAFKA-8474 changed the layout of configuration options on the website from a table which over time ran out of horizontal space to a list. This vastly improved readability but is not yet ideal. Further discussion was had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. This ticket is to move that discussion to a separate thread and make it more visible to other people and to give subsequent PRs a home. Currently proposed options are attached to this issue. was: KAKFA-8474 changed the layout of configuration options on the website from a table which over time ran out of horizontal space to a list. This vastly improved readability but is not yet ideal. Further discussion was had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. This ticket is to move that discussion to a separate thread and make it more visible to other people and to give subsequent PRs a home. Currently proposed options are attached to this issue. > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > Attachments: option1.png, option2.png, option3.png, option4.png > > > KAFKA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-9423) Refine layout of configuration options on website and make individual settings directly linkable
[ https://issues.apache.org/jira/browse/KAFKA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017063#comment-17017063 ] Sönke Liebau commented on KAFKA-9423: - Thinking this a little further, is there any appetite for replacing all that string concatenation with some form of HTML generation lib? I've just used [j2html|https://j2html.com/] and found it fairly lightweight and usable. Since that code is not needed at runtime but only to build the site during the Gradle run we could probably just have it as a compile only dependency and not clutter the release tars with any additional dependencies. > Refine layout of configuration options on website and make individual > settings directly linkable > > > Key: KAFKA-9423 > URL: https://issues.apache.org/jira/browse/KAFKA-9423 > Project: Kafka > Issue Type: Improvement > Components: documentation >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Trivial > Attachments: option1.png, option2.png, option3.png, option4.png > > > KAFKA-8474 changed the layout of configuration options on the website from a > table which over time ran out of horizontal space to a list. > This vastly improved readability but is not yet ideal. Further discussion was > had in the [PR|https://github.com/apache/kafka/pull/6870] for KAFKA-8474. > This ticket is to move that discussion to a separate thread and make it more > visible to other people and to give subsequent PRs a home. > Currently proposed options are attached to this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (KAFKA-9456) EndToEndLatency: Add support for printing all latencies
Fábio Silva created KAFKA-9456: -- Summary: EndToEndLatency: Add support for printing all latencies Key: KAFKA-9456 URL: https://issues.apache.org/jira/browse/KAFKA-9456 Project: Kafka Issue Type: New Feature Components: tools Reporter: Fábio Silva Assignee: Fábio Silva The EndToEndLatency tool already stores all the latencies but it only prints a brief report containing the mean latency and some percentiles. The main idea of this feature is to have a flag to enable printing all the latencies instead of a report. Printing all the latencies is important if the goal of testing is to plot a chart (such a boxplot) for example, extract confidence intervals, wherever. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-9456) EndToEndLatency: Add support for printing all latencies
[ https://issues.apache.org/jira/browse/KAFKA-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fábio Silva updated KAFKA-9456: --- Priority: Minor (was: Major) > EndToEndLatency: Add support for printing all latencies > --- > > Key: KAFKA-9456 > URL: https://issues.apache.org/jira/browse/KAFKA-9456 > Project: Kafka > Issue Type: New Feature > Components: tools >Reporter: Fábio Silva >Assignee: Fábio Silva >Priority: Minor > Labels: pull-request-available > > The EndToEndLatency tool already stores all the latencies but it only prints > a brief report containing the mean latency and some percentiles. The main > idea of this feature is to have a flag to enable printing all the latencies > instead of a report. > Printing all the latencies is important if the goal of testing is to plot a > chart (such a boxplot) for example, extract confidence intervals, wherever. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-8843) Zookeeper migration tool support for TLS
[
https://issues.apache.org/jira/browse/KAFKA-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024606#comment-17024606
]
Gérald Quintana commented on KAFKA-8843:
I am probably dreaming, but it would be great to have
_zookeeper-client.properties_ config file on par with
producer/consumer.properties config files, containing both TLS and JAAS
authentication settings:
{code:java}
zookeeper.client.secure=true
zookeeper.sasl.jaas.config=org.apache.zookeeper.server.auth.DigestLoginModule
required username="kafka" password="kafkapass";
zookeeper.ssl.truststore.location=/etc/kafka/truststore.jks
zookeeper.ssl.truststore.password=truststorepass
{code}
As a result, the command line argument could be named _-zk-config-file_ instead
of _-zk-tls-config-file_
> Zookeeper migration tool support for TLS
>
>
> Key: KAFKA-8843
> URL: https://issues.apache.org/jira/browse/KAFKA-8843
> Project: Kafka
> Issue Type: Bug
>Reporter: Pere Urbon-Bayes
>Assignee: Pere Urbon-Bayes
>Priority: Minor
>
> Currently zookeeper-migration tool works based on SASL authentication. What
> means only digest and kerberos authentication is supported.
>
> With the introduction of ZK 3.5, TLS is added, including a new X509
> authentication provider.
>
> To support this great future and utilise the TLS principals, the
> zookeeper-migration-tool script should support the X509 authentication as
> well.
>
> In my newbie view, this should mean adding a new parameter to allow other
> ways of authentication around
> [https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/admin/ZkSecurityMigrator.scala#L65.
>
> |https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/admin/ZkSecurityMigrator.scala#L65]
>
> If I understand the process correct, this will require a KIP, right?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-8843) Zookeeper migration tool support for TLS
[
https://issues.apache.org/jira/browse/KAFKA-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024606#comment-17024606
]
Gérald Quintana edited comment on KAFKA-8843 at 1/27/20 7:39 PM:
-
I am probably dreaming, but it would be great to have
_zookeeper-client.properties_ config file on par with
producer/consumer.properties config files, containing both TLS and optionnaly
JAAS authentication settings:
{code:java}
zookeeper.client.secure=true
zookeeper.sasl.jaas.config=org.apache.zookeeper.server.auth.DigestLoginModule
required username="kafka" password="kafkapass";
zookeeper.ssl.truststore.location=/etc/kafka/truststore.jks
zookeeper.ssl.truststore.password=truststorepass
{code}
As a result, the command line argument could be named _-zk-config-file_ instead
of _-zk-tls-config-file_
was (Author: gquintana):
I am probably dreaming, but it would be great to have
_zookeeper-client.properties_ config file on par with
producer/consumer.properties config files, containing both TLS and JAAS
authentication settings:
{code:java}
zookeeper.client.secure=true
zookeeper.sasl.jaas.config=org.apache.zookeeper.server.auth.DigestLoginModule
required username="kafka" password="kafkapass";
zookeeper.ssl.truststore.location=/etc/kafka/truststore.jks
zookeeper.ssl.truststore.password=truststorepass
{code}
As a result, the command line argument could be named _-zk-config-file_ instead
of _-zk-tls-config-file_
> Zookeeper migration tool support for TLS
>
>
> Key: KAFKA-8843
> URL: https://issues.apache.org/jira/browse/KAFKA-8843
> Project: Kafka
> Issue Type: Bug
>Reporter: Pere Urbon-Bayes
>Assignee: Pere Urbon-Bayes
>Priority: Minor
>
> Currently zookeeper-migration tool works based on SASL authentication. What
> means only digest and kerberos authentication is supported.
>
> With the introduction of ZK 3.5, TLS is added, including a new X509
> authentication provider.
>
> To support this great future and utilise the TLS principals, the
> zookeeper-migration-tool script should support the X509 authentication as
> well.
>
> In my newbie view, this should mean adding a new parameter to allow other
> ways of authentication around
> [https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/admin/ZkSecurityMigrator.scala#L65.
>
> |https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/admin/ZkSecurityMigrator.scala#L65]
>
> If I understand the process correct, this will require a KIP, right?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (KAFKA-9504) Memory leak in KafkaMetrics registered to MBean
Andreas Holmén created KAFKA-9504:
-
Summary: Memory leak in KafkaMetrics registered to MBean
Key: KAFKA-9504
URL: https://issues.apache.org/jira/browse/KAFKA-9504
Project: Kafka
Issue Type: Bug
Components: clients
Affects Versions: 2.4.0
Reporter: Andreas Holmén
After close() called on a KafkaConsumer some registered MBeans are not
unregistered causing leak.
{code:java}
import static
org.apache.kafka.clients.consumer.ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG;
import java.lang.management.ManagementFactory;
import java.util.HashMap;
import java.util.Map;
import javax.management.MBeanServer;
import org.apache.kafka.clients.consumer.KafkaConsumer;
import org.apache.kafka.common.serialization.ByteArrayDeserializer;
public class Leaker {
private static String bootstrapServers = "hostname:9092";
public static void main(String[] args) throws InterruptedException {
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
Map props = new HashMap<>();
props.put(BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
int beans = mBeanServer.getMBeanCount();
for (int i = 0; i < 100; i++) {
KafkaConsumer consumer = new KafkaConsumer<>(props, new
ByteArrayDeserializer(), new ByteArrayDeserializer());
consumer.close();
}
int newBeans = mBeanServer.getMBeanCount();
System.out.println("\nbeans delta: " + (newBeans - beans));
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (KAFKA-9543) Consumer offset reset after new segment rolling
Rafał Boniecki created KAFKA-9543:
-
Summary: Consumer offset reset after new segment rolling
Key: KAFKA-9543
URL: https://issues.apache.org/jira/browse/KAFKA-9543
Project: Kafka
Issue Type: Bug
Affects Versions: 2.4.0
Reporter: Rafał Boniecki
Attachments: Untitled.png
After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
offset resets.
Consumer:
{code:java}
2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
[2020-02-12T11:12:58,402][INFO
][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of range
for partition stats-5, resetting offset
{code}
Broker:
{code:java}
2020-02-12 11:12:58:400 CET INFO
[data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
All resets are perfectly correlated to rolling new segments at the broker -
segment is rolled first, then, couple of ms later, reset on the consumer
occurs. Attached is grafana graph with consumer lag per partition. All sudden
spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039336#comment-17039336
]
Rafał Boniecki commented on KAFKA-9543:
---
Yes it is consumer lag. As you can see before update there was practically none
of it (it can be easily deduced when upgrade took place ;)). I will try to
reproduce it and let you know how it went.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039336#comment-17039336
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/18/20 6:33 PM:
Yes it is consumer lag (every color represents different partition). As you can
see before update there was practically none of it (it can be easily deduced
when upgrade took place ;)). I will try to reproduce it and let you know how it
went.
was (Author: boniek):
Yes it is consumer lag. As you can see before update there was practically none
of it (it can be easily deduced when upgrade took place ;)). I will try to
reproduce it and let you know how it went.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-9609) Memory Leak in Kafka Producer
[ https://issues.apache.org/jira/browse/KAFKA-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045652#comment-17045652 ] Sönke Liebau commented on KAFKA-9609: - Is that really a bug though? If I checked the record-send-total, record-error-total or byte-total metrics for a specific topic I would expect to get the correct number reported no matter how long ago I sent the last record to that topic. I would say that this works as designed, even though it may not be perfect for your use case. > Memory Leak in Kafka Producer > - > > Key: KAFKA-9609 > URL: https://issues.apache.org/jira/browse/KAFKA-9609 > Project: Kafka > Issue Type: Bug > Components: clients, producer >Affects Versions: 2.4.0 >Reporter: Satish >Priority: Major > > org.apache.kafka.clients.producer.internals.Sender adds Topic Metrics for > every topic that we are writing messages to but it never been cleaned up > until we close the producer. > This is an issue if we use single producer and have more number of Dynamic > topics (eg: ~ 500 topics per hour) and writing messages to them. As this > Metrics map is getting accumulated for every topic, over a period of time we > notice the memory usage gets increased gradually. > It can be easily reproducible by writing messages to the more # of dynamic > topics using the same KafkaProducer from apache kafka client libraries or > KafkaTemplate from Spring. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-9609) Memory Leak in Kafka Producer
[ https://issues.apache.org/jira/browse/KAFKA-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045741#comment-17045741 ] Sönke Liebau commented on KAFKA-9609: - Hi [~satish.gudl...@gmail.com], I am not aware of any way to remove Producer metrics tbh. Just had a quick look (2 minutes) at the code and couldn't find anything either. If this is a problem for you, it would probably be best to periodically reinitialize your producers, how that would best be done depends heavily on how you use them though. Using a 1:1 assignment of producer to topic is one option - if it is a sensible one depends again on your setup though. > Memory Leak in Kafka Producer > - > > Key: KAFKA-9609 > URL: https://issues.apache.org/jira/browse/KAFKA-9609 > Project: Kafka > Issue Type: Bug > Components: clients, producer >Affects Versions: 2.4.0 >Reporter: Satish >Priority: Major > > org.apache.kafka.clients.producer.internals.Sender adds Topic Metrics for > every topic that we are writing messages to but it never been cleaned up > until we close the producer. > This is an issue if we use single producer and have more number of Dynamic > topics (eg: ~ 500 topics per hour) and writing messages to them. As this > Metrics map is getting accumulated for every topic, over a period of time we > notice the memory usage gets increased gradually. > It can be easily reproducible by writing messages to the more # of dynamic > topics using the same KafkaProducer from apache kafka client libraries or > KafkaTemplate from Spring. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (KAFKA-9609) Memory Leak in Kafka Producer
[ https://issues.apache.org/jira/browse/KAFKA-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sönke Liebau resolved KAFKA-9609. - Assignee: Sönke Liebau Resolution: Not A Bug As discussed in the comments I do not believe that this is a bug. Yes, memory usage may increase over time with this usage pattern, but it is not a memory leak, as the information needs to be kept in order to report correct metrics. > Memory Leak in Kafka Producer > - > > Key: KAFKA-9609 > URL: https://issues.apache.org/jira/browse/KAFKA-9609 > Project: Kafka > Issue Type: Bug > Components: clients, producer >Affects Versions: 2.4.0 >Reporter: Satish >Assignee: Sönke Liebau >Priority: Major > > org.apache.kafka.clients.producer.internals.Sender adds Topic Metrics for > every topic that we are writing messages to but it never been cleaned up > until we close the producer. > This is an issue if we use single producer and have more number of Dynamic > topics (eg: ~ 500 topics per hour) and writing messages to them. As this > Metrics map is getting accumulated for every topic, over a period of time we > notice the memory usage gets increased gradually. > It can be easily reproducible by writing messages to the more # of dynamic > topics using the same KafkaProducer from apache kafka client libraries or > KafkaTemplate from Spring. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-9613) orruptRecordException: Found record size 0 smaller than minimum record overhead
[ https://issues.apache.org/jira/browse/KAFKA-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046407#comment-17046407 ] Sönke Liebau commented on KAFKA-9613: - Hi [~khandelwal.amit] can you please provide some additional information around this bug? Especially helpful would be any steps that might help reproduce this scenario, if you've done some testing around this. What version of Kafka are you using on the brokers and on the clients? Did you at any time upgrade or downgrade your brokers? Does this error always occur in the same file or in multiple ones? > orruptRecordException: Found record size 0 smaller than minimum record > overhead > --- > > Key: KAFKA-9613 > URL: https://issues.apache.org/jira/browse/KAFKA-9613 > Project: Kafka > Issue Type: Bug >Reporter: Amit Khandelwal >Priority: Major > > 20200224;21:01:38: [2020-02-24 21:01:38,615] ERROR [ReplicaManager broker=0] > Error processing fetch with max size 1048576 from consumer on partition > SANDBOX.BROKER.NEWORDER-0: (fetchOffset=211886, logStartOffset=-1, > maxBytes=1048576, currentLeaderEpoch=Optional.empty) > (kafka.server.ReplicaManager) > 20200224;21:01:38: org.apache.kafka.common.errors.CorruptRecordException: > Found record size 0 smaller than minimum record overhead (14) in file > /data/tmp/kafka-topic-logs/SANDBOX.BROKER.NEWORDER-0/.log. > 20200224;21:05:48: [2020-02-24 21:05:48,711] INFO [GroupMetadataManager > brokerId=0] Removed 0 expired offsets in 1 milliseconds. > (kafka.coordinator.group.GroupMetadataManager) > 20200224;21:10:22: [2020-02-24 21:10:22,204] INFO [GroupCoordinator 0]: > Member > _011-9e61d2c9-ce5a-4231-bda1-f04e6c260dc0-StreamThread-1-consumer-27768816-ee87-498f-8896-191912282d4f > in group y_011 has failed, removing it from the group > (kafka.coordinator.group.GroupCoordinator) > > [https://stackoverflow.com/questions/60404510/kafka-broker-issue-replica-manager-with-max-size#] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-8247) Duplicate error handling in kafka-server-start.sh and actual Kafka class
[ https://issues.apache.org/jira/browse/KAFKA-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046960#comment-17046960 ] Sönke Liebau commented on KAFKA-8247: - ping [~hachikuji] > Duplicate error handling in kafka-server-start.sh and actual Kafka class > > > Key: KAFKA-8247 > URL: https://issues.apache.org/jira/browse/KAFKA-8247 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 2.1.1 >Reporter: Sönke Liebau >Assignee: Sönke Liebau >Priority: Minor > > There is some duplication of error handling for command line parameters that > are passed into kafka-server-start.sh > > The shell script prints an error, if no arguments are passed in, effectively > causing the same check in > [Kafka|https://github.com/apache/kafka/blob/92db08cba582668d77160b0c2853efd45a1b809b/core/src/main/scala/kafka/Kafka.scala#L43] > to never be triggered, unless the only option that is specified is -daemon, > which would be removed before passing arguments to the java class. > > While not in any way critical I don't think that this is intended behavior. I > think we should remove the extra check in kafka-server-start.sh and leave > argument handling up to the Kafka class. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki commented on KAFKA-9543:
---
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we seen this happen has about 5MB/s traffic (so not that much
traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic and read it back at the same time as it was written and cannot
reproduce this
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 2:54 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic and read it back at the same time as it was written and cannot
reproduce this
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we seen this happen has about 5MB/s traffic (so not that much
traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic and read it back at the same time as it was written and cannot
reproduce this
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 2:55 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic and read it back at the same time as it was written and cannot
reproduce this
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 2:56 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this - test ran 3 days - we looked
for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 2:57 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this - test ran 3 days - we looked
for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 2:59 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:01 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx). This suggests that maybe offsets are incorrectly
cached or cache update has race condition.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx)
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:05 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx). This suggests that maybe offsets are incorrectly
cached or cache update has race condition. Also notice that before update
client had 0 lag, so probably this is crucial to reproduce this bug - you have
to be reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx). This suggests that maybe offsets are incorrectly
cached or cache update has race condition.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:08 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx). This suggests that maybe offsets are incorrectly
cached or cache update has race condition. Also notice that before update
client had 0 lag (you can see this in my attached screenshot), so probably this
is crucial to reproduce this bug - you have to be reading top of the log
all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx). This suggests that maybe offsets are incorrectly
cached or cache update has race condition. Also notice that before update
client had 0 lag, so probably this is crucial to reproduce this bug - you have
to be reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:09 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". I assume kafka broker thinks it does not have this offset in log
(at least according to data we gather from jmx). This suggests that maybe
offsets are incorrectly cached or cache update has race condition. Also notice
that before update client had 0 lag (you can see this in my attached
screenshot), so probably this is crucial to reproduce this bug - you have to be
reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". Kafka broker does not have this offset in log (at least according
to data we gather from jmx). This suggests that maybe offsets are incorrectly
cached or cache update has race condition. Also notice that before update
client had 0 lag (you can see this in my attached screenshot), so probably this
is crucial to reproduce this bug - you have to be reading top of the log
all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:11 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future" (top, not bottom of the log). I assume kafka broker thinks it does
not have this offset in log (at least according to data we gather from jmx).
This suggests that maybe offsets are incorrectly cached or cache update has
race condition. Also notice that before update client had 0 lag (you can see
this in my attached screenshot), so probably this is crucial to reproduce this
bug - you have to be reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future". I assume kafka broker thinks it does not have this offset in log
(at least according to data we gather from jmx). This suggests that maybe
offsets are incorrectly cached or cache update has race condition. Also notice
that before update client had 0 lag (you can see this in my attached
screenshot), so probably this is crucial to reproduce this bug - you have to be
reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:12 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future" (top, not bottom of the log). I assume kafka broker thinks it does
not have this offset in log. This assumption is based on low resolution (every
5 minutes) offset data we gather from jmx. This suggests that maybe offsets are
incorrectly cached or cache update has race condition. Also notice that before
update client had 0 lag (you can see this in my attached screenshot), so
probably this is crucial to reproduce this bug - you have to be reading top of
the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future" (top, not bottom of the log). I assume kafka broker thinks it does
not have this offset in log (at least according to data we gather from jmx).
This suggests that maybe offsets are incorrectly cached or cache update has
race condition. Also notice that before update client had 0 lag (you can see
this in my attached screenshot), so probably this is crucial to reproduce this
bug - you have to be reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:24 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future" (top, not bottom of the log). I assume kafka broker thinks it does
not have this offset in log. This assumption is based on low resolution (every
5 minutes) offset data (star and end of the partition log) we gather from jmx.
This suggests that maybe offsets are incorrectly cached or cache update has
race condition. Also notice that before update client had 0 lag (you can see
this in my attached screenshot), so probably this is crucial to reproduce this
bug - you have to be reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future" (top, not bottom of the log). I assume kafka broker thinks it does
not have this offset in log. This assumption is based on low resolution (every
5 minutes) offset data we gather from jmx. This suggests that maybe offsets are
incorrectly cached or cache update has race condition. Also notice that before
update client had 0 lag (you can see this in my attached screenshot), so
probably this is crucial to reproduce this bug - you have to be reading top of
the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-9543) Consumer offset reset after new segment rolling
[
https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047711#comment-17047711
]
Rafał Boniecki edited comment on KAFKA-9543 at 2/28/20 3:24 PM:
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future" (top, not bottom of the log). I assume kafka broker thinks it does
not have this offset in log. This assumption is based on low resolution (every
5 minutes) offset data (start and end of the partition log) we gather from jmx.
This suggests that maybe offsets are incorrectly cached or cache update has
race condition. Also notice that before update client had 0 lag (you can see
this in my attached screenshot), so probably this is crucial to reproduce this
bug - you have to be reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
was (Author: boniek):
I cannot reproduce it on my development environment. Couple of facts to add
what Brian wrote:
* This indeed does not happen on every segment rollover, but when it happens
it is always on segment rollover
* We have no compacted topics in our production cluster, so topic type doesn't
matter.
* No topic in our production environment starts at offset 0 - so this doesn't
matter as well.
* Topic where we definetly seen this happen has about 5MB/s traffic (so not
that much traffic)
* Fetch offset ... is out of range for partition is always about offset "from
the future" (top, not bottom of the log). I assume kafka broker thinks it does
not have this offset in log. This assumption is based on low resolution (every
5 minutes) offset data (star and end of the partition log) we gather from jmx.
This suggests that maybe offsets are incorrectly cached or cache update has
race condition. Also notice that before update client had 0 lag (you can see
this in my attached screenshot), so probably this is crucial to reproduce this
bug - you have to be reading top of the log all/most of the time to hit this.
* we tested this in our development environment, where we load generated about
5MB/s traffic (using kafka-producer-perf-test.sh) and read it back (using
identically , as in production environment, configured consumer) at the same
time as it was written and cannot reproduce this. Test ran for 3 days non stop
- we looked for offset resets and there were none.
> Consumer offset reset after new segment rolling
> ---
>
> Key: KAFKA-9543
> URL: https://issues.apache.org/jira/browse/KAFKA-9543
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Rafał Boniecki
>Priority: Major
> Attachments: Untitled.png
>
>
> After upgrade from kafka 2.1.1 to 2.4.0, I'm experiencing unexpected consumer
> offset resets.
> Consumer:
> {code:java}
> 2020-02-12T11:12:58.402+01:00 hostname 4a2a39a35a02
> [2020-02-12T11:12:58,402][INFO
> ][org.apache.kafka.clients.consumer.internals.Fetcher] [Consumer
> clientId=logstash-1, groupId=logstash] Fetch offset 1632750575 is out of
> range for partition stats-5, resetting offset
> {code}
> Broker:
> {code:java}
> 2020-02-12 11:12:58:400 CET INFO
> [data-plane-kafka-request-handler-1][kafka.log.Log] [Log partition=stats-5,
> dir=/kafka4/data] Rolled new log segment at offset 1632750565 in 2 ms.{code}
> All resets are perfectly correlated to rolling new segments at the broker -
> segment is rolled first, then, couple of ms later, reset on the consumer
> occurs. Attached is grafana graph with consumer lag per partition. All sudden
> spikes in lag are offset resets due to this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-7544) Transient Failure: org.apache.kafka.streams.integration.EosIntegrationTest.shouldNotViolateEosIfOneTaskFails
[
https://issues.apache.org/jira/browse/KAFKA-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17048107#comment-17048107
]
点儿郎当 commented on KAFKA-7544:
-
Can you pack it or not?
> Transient Failure:
> org.apache.kafka.streams.integration.EosIntegrationTest.shouldNotViolateEosIfOneTaskFails
>
>
> Key: KAFKA-7544
> URL: https://issues.apache.org/jira/browse/KAFKA-7544
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Reporter: John Roesler
>Priority: Major
>
> Observed on Java 11:
> [https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/264/testReport/junit/org.apache.kafka.streams.integration/EosIntegrationTest/shouldNotViolateEosIfOneTaskFails/]
> at
> [https://github.com/apache/kafka/pull/5795/commits/5bdcd0e023c6f406d585155399f6541bb6a9f9c2]
>
> stacktrace:
> {noformat}
> java.lang.AssertionError:
> Expected: <[KeyValue(0, 0), KeyValue(0, 1), KeyValue(0, 2), KeyValue(0, 3),
> KeyValue(0, 4), KeyValue(0, 5), KeyValue(0, 6), KeyValue(0, 7), KeyValue(0,
> 8), KeyValue(0, 9)]>
> but: was <[KeyValue(0, 0), KeyValue(0, 1), KeyValue(0, 2), KeyValue(0,
> 3), KeyValue(0, 4), KeyValue(0, 5), KeyValue(0, 6), KeyValue(0, 7),
> KeyValue(0, 8), KeyValue(0, 9), KeyValue(0, 10), KeyValue(0, 11), KeyValue(0,
> 12), KeyValue(0, 13), KeyValue(0, 14)]>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
> at
> org.apache.kafka.streams.integration.EosIntegrationTest.checkResultPerKey(EosIntegrationTest.java:218)
> at
> org.apache.kafka.streams.integration.EosIntegrationTest.shouldNotViolateEosIfOneTaskFails(EosIntegrationTest.java:360)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
>
[jira] [Created] (KAFKA-9639) Task is not killed despite being dead
Stéphane Derosiaux created KAFKA-9639:
-
Summary: Task is not killed despite being dead
Key: KAFKA-9639
URL: https://issues.apache.org/jira/browse/KAFKA-9639
Project: Kafka
Issue Type: Bug
Components: KafkaConnect
Affects Versions: 2.3.1
Reporter: Stéphane Derosiaux
After restarting my postgresql, my Debezium connector failed and stopped (no
more metrics, and see the logs below), but the task and the connector in
Connect were still "RUNNING".
It seems the task "stop" procedure was interrupted by the Kafka Connect
framework and let the connector in a "zombie" state.
{code:java}
WorkerSourceTask\{id=customer-order-cdc-0} Task threw an uncaught and
unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask:179)
org.apache.kafka.connect.errors.ConnectException: An exception occurred in the
change event producer. This connector will be stopped.
Caused by: org.postgresql.util.PSQLException: Database connection failed when
reading from copy
WorkerSourceTask\{id=customer-order-cdc-0} Task is being killed and will not
recover until manually restarted
(org.apache.kafka.connect.runtime.WorkerTask:180)
Creating thread debezium-postgresconnector-customer-order-dev-error-handler
(io.debezium.util.Threads:268)
Connector has already been stopped
(io.debezium.connector.postgresql.PostgresConnectorTask:241)
Finished streaming (io.debezium.pipeline.ChangeEventSourceCoordinator:100)
Connected metrics set to 'false'
(io.debezium.pipeline.metrics.StreamingChangeEventSourceMetrics:59)
[2020-03-02 08:48:08,074] ERROR [customer-order-cdc|task-0] Interrupted while
stopping (io.debezium.connector.postgresql.PostgresConnectorTask:263)
java.lang.InterruptedException
[Producer clientId=connector-producer-customer-order-cdc-0] Closing the Kafka
producer with timeoutMillis = 3 ms.
(org.apache.kafka.clients.producer.KafkaProducer:1153)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (KAFKA-9106) metrics exposed via JMX shoud be configurable
[ https://issues.apache.org/jira/browse/KAFKA-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Léauté resolved KAFKA-9106. -- Fix Version/s: 2.5.0 Resolution: Fixed > metrics exposed via JMX shoud be configurable > - > > Key: KAFKA-9106 > URL: https://issues.apache.org/jira/browse/KAFKA-9106 > Project: Kafka > Issue Type: Improvement > Components: metrics >Reporter: Xavier Léauté >Assignee: Xavier Léauté >Priority: Major > Fix For: 2.5.0 > > > Kafka exposes a very large number of metrics, all of which are always visible > in JMX by default. On large clusters with many partitions, this may result in > tens of thousands of mbeans to be registered, which can lead to timeouts with > some popular monitoring agents that rely on listing JMX metrics via RMI. > Making the set of JMX-visible metrics configurable would allow operators to > decide on the set of critical metrics to collect and workaround limitation of > JMX in those cases. > corresponding KIP > https://cwiki.apache.org/confluence/display/KAFKA/KIP-544%3A+Make+metrics+exposed+via+JMX+configurable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (KAFKA-9647) Add ability to suppress until window end (not close)
Sören Henning created KAFKA-9647: Summary: Add ability to suppress until window end (not close) Key: KAFKA-9647 URL: https://issues.apache.org/jira/browse/KAFKA-9647 Project: Kafka Issue Type: Wish Components: streams Reporter: Sören Henning *Preface:* This feature request originates from a [recently asked question on Stack Overflow|https://stackoverflow.com/questions/60005630/kafka-streams-suppress-until-window-end-not-close], for which Matthias J. Sax suggested to create a feature request. *Feature Request:* In addition to suppressing updates to a windowed KTable until a window closes, we suggest to only suppress "early" results. By early results we mean results computed before the window ends, but not those results occurring during the grace period. Thus, this suppress option would suppress all aggregation results with timestamp < window end, but forward all records with timestamp >= window end and timestamp < window close. *Use Case:* For an exemplary use case, we refer to John Roesler's [blog post on the initial introduction of the suppress operator|https://www.confluent.io/blog/kafka-streams-take-on-watermarks-and-triggers/]. The post argues that for the case of altering not every intermediate aggregation result should trigger an alert message, but only the "final" result. Otherwise, a "follow-up email telling people to ignore the first message" might become required if the final results would not cause an alert but intermediate results would. Kafka Streams' current solution for this use case would be to use a suppress operation, which would only forward the final result, which would be the last result before no further updates could occur. This is when the grace period of a window passed (the window closes). However, ideally we would like to set the grace period a large as possible to allow for very late-arriving messages, which in turn would lead to very late alerts. On the other hand, such late-arriving messages are rare in practice and normally the order of events corresponds largely to the order of messages. Thus, a reasonable option would be to suppress aggregation results only until the window ends (i.e. stream time > window end) and then forward this "most likely final" result. For the use case of altering, this means an alert is triggered when we are relatively certain that recorded data requires an alert. Then, only the "seldom" case of late updates which would change our decision would require the "follow-up email telling people to ignore the first message". Such rare "correction" should be acceptable for many use cases. *Further extension:* In addition to suppressing all updates until the window ends and afterwards forwarding all updates, a further extension would be to only forward late records every x seconds. Maybe the existing `Suppressed.untilTimeLimit( .. )` could be reused for this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (KAFKA-9649) Remove/Warn on use of TimeWindowedSerde with no specified window size
Sören Henning created KAFKA-9649:
Summary: Remove/Warn on use of TimeWindowedSerde with no specified
window size
Key: KAFKA-9649
URL: https://issues.apache.org/jira/browse/KAFKA-9649
Project: Kafka
Issue Type: Improvement
Components: streams
Reporter: Sören Henning
The API of the
[{{TimeWindowedSerde}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/WindowedSerdes.java]
promotes its construction without specifying a window size:
{noformat}
public TimeWindowedSerde(final Serde inner)
{noformat}
While code using this constructor looks absolutely clean, it leads to fatal
errors at runtime, which turned out to be very hard to discover.
The reason for these error can be found in the construction of the
[{{TimeWindowedDeserializer}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/TimeWindowedDeserializer.java],
which is created via:
{noformat}
// TODO: fix this part as last bits of KAFKA-4468
public TimeWindowedDeserializer(final Deserializer inner) {
this(inner, Long.MAX_VALUE);
}
{noformat}
The TODO comment suggests that this issue is (or at least was) already known.
We suggest to either remove the {{TimeWindowedSerde(final Serde inner)}}
constructor or at least to warn when using it (if required for backwards
compatiblity). The ideal solution of course would be to get the window size
from some externally provided context. However, I expect this to be difficult
to realize. Same applies also the {{TimeWindowedDeserializer(final
Deserializer inner)}} constructor.
A further minor suggestion in this context: As now most Kafka Streams time
declarations use {{Duration}}s instead of long-encoded millisseconds, I suggest
to allow specifying window sizes with a {{Duration}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KAFKA-9649) Remove/Warn on use of TimeWindowedSerde with no specified window size
[
https://issues.apache.org/jira/browse/KAFKA-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sören Henning updated KAFKA-9649:
-
Description:
The API of the
[{{TimeWindowedSerde}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/WindowedSerdes.java]
promotes its construction without specifying a window size:
{noformat}
public TimeWindowedSerde(final Serde inner)
{noformat}
While code using this constructor looks absolutely clean, it leads to fatal
errors at runtime, which turned out to be very hard to discover.
The reason for these error can be found in the construction of the
[{{TimeWindowedDeserializer}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/TimeWindowedDeserializer.java],
which is created via:
{noformat}
// TODO: fix this part as last bits of KAFKA-4468
public TimeWindowedDeserializer(final Deserializer inner) {
this(inner, Long.MAX_VALUE);
}
{noformat}
The TODO comment suggests that this issue is (or at least was) already known.
We suggest to either remove the {{TimeWindowedSerde(final Serde inner)}}
constructor or at least to warn when using it (if required for backwards
compatiblity). The ideal solution of course would be to get the window size
from some externally provided context. However, I expect this to be difficult
to realize. Same applies also the {{TimeWindowedDeserializer(final
Deserializer inner)}} constructor.
A further minor suggestion in this context: As now most Kafka Streams time
declarations use {{Duration}} s instead of long-encoded milliseconds, I suggest
to allow specifying window sizes with a {{Duration}}.
was:
The API of the
[{{TimeWindowedSerde}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/WindowedSerdes.java]
promotes its construction without specifying a window size:
{noformat}
public TimeWindowedSerde(final Serde inner)
{noformat}
While code using this constructor looks absolutely clean, it leads to fatal
errors at runtime, which turned out to be very hard to discover.
The reason for these error can be found in the construction of the
[{{TimeWindowedDeserializer}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/TimeWindowedDeserializer.java],
which is created via:
{noformat}
// TODO: fix this part as last bits of KAFKA-4468
public TimeWindowedDeserializer(final Deserializer inner) {
this(inner, Long.MAX_VALUE);
}
{noformat}
The TODO comment suggests that this issue is (or at least was) already known.
We suggest to either remove the {{TimeWindowedSerde(final Serde inner)}}
constructor or at least to warn when using it (if required for backwards
compatiblity). The ideal solution of course would be to get the window size
from some externally provided context. However, I expect this to be difficult
to realize. Same applies also the {{TimeWindowedDeserializer(final
Deserializer inner)}} constructor.
A further minor suggestion in this context: As now most Kafka Streams time
declarations use {{Duration}}s instead of long-encoded millisseconds, I suggest
to allow specifying window sizes with a {{Duration}}.
> Remove/Warn on use of TimeWindowedSerde with no specified window size
> -
>
> Key: KAFKA-9649
> URL: https://issues.apache.org/jira/browse/KAFKA-9649
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: Sören Henning
>Priority: Major
>
> The API of the
> [{{TimeWindowedSerde}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/WindowedSerdes.java]
> promotes its construction without specifying a window size:
> {noformat}
> public TimeWindowedSerde(final Serde inner)
> {noformat}
> While code using this constructor looks absolutely clean, it leads to fatal
> errors at runtime, which turned out to be very hard to discover.
> The reason for these error can be found in the construction of the
> [{{TimeWindowedDeserializer}}|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/TimeWindowedDeserializer.java],
> which is created via:
> {noformat}
> // TODO: fix this part as last bits of KAFKA-4468
> public TimeWindowedDeserializer(final Deserializer inner) {
> this(inner, Long.MAX_VALUE);
> }
> {noformat}
> The TODO comment suggests that this issue is (or at least was) already known.
> We suggest to either remove the {{TimeWindowedSerde(final Serde inner)}}
> constructor or at least to warn when using it (if required for backwards
> compatiblity). The ideal solution of course would be to get the wi
[jira] [Created] (KAFKA-9671) Support sha512sum file format
Aljoscha Pörtner created KAFKA-9671:
---
Summary: Support sha512sum file format
Key: KAFKA-9671
URL: https://issues.apache.org/jira/browse/KAFKA-9671
Project: Kafka
Issue Type: Improvement
Components: packaging
Affects Versions: 2.4.0
Reporter: Aljoscha Pörtner
The generated *.tgz.sha512 can not be checked using sha512sum -c because of a
wrong file format generated by GPG. The problem applies to *.tgz.md5 and
*.tgz.sha1 aswell.
Current format:
{code:java}
kafka_2.12-2.4.0.tgz: 53B52F86 EA56C9FA C6204652 4F03F756 65A089EA 2DAE554A
EFE3A3D2 694F2DA8 8B5BA872 5D8BE55F 198BA806 95443559
ED9DE7C0 B2A2817F 7A614100 8FF79F49{code}
Expected format:
{code:java}
53b52f86ea56c9fac62046524f03f75665a089ea2dae554aefe3a3d2694f2da88b5ba8725d8be55f198ba80695443559ed9de7c0b2a2817f7a6141008ff79f49
kafka_2.12-2.4.0.tgz
{code}
A fix would help to improve to automate the check, e.g. within Dockerfiles.
*Discussion on the same topic at the Apache Spark project :
[http://apache-spark-developers-list.1001551.n3.nabble.com/Changing-how-we-compute-release-hashes-td23599.html|http://example.com]
Thank you.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-9609) Memory Leak in Kafka Producer
[ https://issues.apache.org/jira/browse/KAFKA-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053313#comment-17053313 ] Sönke Liebau commented on KAFKA-9609: - To be honest I still think that this would be the wrong approach to take, as it would "falsify" returned metrics. Maybe as an alternative a setting could be introduced that suppresses per-topic metrics in the producer? That should also be a solution to your use-case if I am not mistaken, correct? > Memory Leak in Kafka Producer > - > > Key: KAFKA-9609 > URL: https://issues.apache.org/jira/browse/KAFKA-9609 > Project: Kafka > Issue Type: Bug > Components: clients, producer >Affects Versions: 2.4.0 >Reporter: Satish >Assignee: Sönke Liebau >Priority: Major > > org.apache.kafka.clients.producer.internals.Sender adds Topic Metrics for > every topic that we are writing messages to but it never been cleaned up > until we close the producer. > This is an issue if we use single producer and have more number of Dynamic > topics (eg: ~ 500 topics per hour) and writing messages to them. As this > Metrics map is getting accumulated for every topic, over a period of time we > notice the memory usage gets increased gradually. > It can be easily reproducible by writing messages to the more # of dynamic > topics using the same KafkaProducer from apache kafka client libraries or > KafkaTemplate from Spring. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
