[jira] [Commented] (KAFKA-7895) Ktable supress operator emitting more than one record for the same key per window
[
https://issues.apache.org/jira/browse/KAFKA-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936404#comment-16936404
]
Matthias J. Sax commented on KAFKA-7895:
This won't fix for 2.1.2 due to backward compatibility issues – reverting the
back port.
> Ktable supress operator emitting more than one record for the same key per
> window
> -
>
> Key: KAFKA-7895
> URL: https://issues.apache.org/jira/browse/KAFKA-7895
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 2.1.0, 2.2.0, 2.1.1
>Reporter: prasanthi
>Assignee: John Roesler
>Priority: Blocker
> Fix For: 2.3.0, 2.2.1
>
>
> Hi, We are using kstreams to get the aggregated counts per vendor(key) within
> a specified window.
> Here's how we configured the suppress operator to emit one final record per
> key/window.
> {code:java}
> KTable, Long> windowedCount = groupedStream
> .windowedBy(TimeWindows.of(Duration.ofMinutes(1)).grace(ofMillis(5L)))
> .count(Materialized.with(Serdes.Integer(),Serdes.Long()))
> .suppress(Suppressed.untilWindowCloses(unbounded()));
> {code}
> But we are getting more than one record for the same key/window as shown
> below.
> {code:java}
> [KTABLE-TOSTREAM-10]: [131@154906704/154906710], 1039
> [KTABLE-TOSTREAM-10]: [131@154906704/154906710], 1162
> [KTABLE-TOSTREAM-10]: [9@154906704/154906710], 6584
> [KTABLE-TOSTREAM-10]: [88@154906704/154906710], 107
> [KTABLE-TOSTREAM-10]: [108@154906704/154906710], 315
> [KTABLE-TOSTREAM-10]: [119@154906704/154906710], 119
> [KTABLE-TOSTREAM-10]: [154@154906704/154906710], 746
> [KTABLE-TOSTREAM-10]: [154@154906704/154906710], 809{code}
> Could you please take a look?
> Thanks
>
>
> Added by John:
> Acceptance Criteria:
> * add suppress to system tests, such that it's exercised with crash/shutdown
> recovery, rebalance, etc.
> ** [https://github.com/apache/kafka/pull/6278]
> * make sure that there's some system test coverage with caching disabled.
> ** Follow-on ticket: https://issues.apache.org/jira/browse/KAFKA-7943
> * test with tighter time bounds with windows of say 30 seconds and use
> system time without adding any extra time for verification
> ** Follow-on ticket: https://issues.apache.org/jira/browse/KAFKA-7944
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KAFKA-7895) Ktable supress operator emitting more than one record for the same key per window
[
https://issues.apache.org/jira/browse/KAFKA-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias J. Sax updated KAFKA-7895:
---
Fix Version/s: (was: 2.1.2)
> Ktable supress operator emitting more than one record for the same key per
> window
> -
>
> Key: KAFKA-7895
> URL: https://issues.apache.org/jira/browse/KAFKA-7895
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 2.1.0, 2.2.0, 2.1.1
>Reporter: prasanthi
>Assignee: John Roesler
>Priority: Blocker
> Fix For: 2.3.0, 2.2.1
>
>
> Hi, We are using kstreams to get the aggregated counts per vendor(key) within
> a specified window.
> Here's how we configured the suppress operator to emit one final record per
> key/window.
> {code:java}
> KTable, Long> windowedCount = groupedStream
> .windowedBy(TimeWindows.of(Duration.ofMinutes(1)).grace(ofMillis(5L)))
> .count(Materialized.with(Serdes.Integer(),Serdes.Long()))
> .suppress(Suppressed.untilWindowCloses(unbounded()));
> {code}
> But we are getting more than one record for the same key/window as shown
> below.
> {code:java}
> [KTABLE-TOSTREAM-10]: [131@154906704/154906710], 1039
> [KTABLE-TOSTREAM-10]: [131@154906704/154906710], 1162
> [KTABLE-TOSTREAM-10]: [9@154906704/154906710], 6584
> [KTABLE-TOSTREAM-10]: [88@154906704/154906710], 107
> [KTABLE-TOSTREAM-10]: [108@154906704/154906710], 315
> [KTABLE-TOSTREAM-10]: [119@154906704/154906710], 119
> [KTABLE-TOSTREAM-10]: [154@154906704/154906710], 746
> [KTABLE-TOSTREAM-10]: [154@154906704/154906710], 809{code}
> Could you please take a look?
> Thanks
>
>
> Added by John:
> Acceptance Criteria:
> * add suppress to system tests, such that it's exercised with crash/shutdown
> recovery, rebalance, etc.
> ** [https://github.com/apache/kafka/pull/6278]
> * make sure that there's some system test coverage with caching disabled.
> ** Follow-on ticket: https://issues.apache.org/jira/browse/KAFKA-7943
> * test with tighter time bounds with windows of say 30 seconds and use
> system time without adding any extra time for verification
> ** Follow-on ticket: https://issues.apache.org/jira/browse/KAFKA-7944
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KAFKA-8649) Error while rolling update from Kafka Streams 2.0.0 -> Kafka Streams 2.1.0
[
https://issues.apache.org/jira/browse/KAFKA-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias J. Sax updated KAFKA-8649:
---
Fix Version/s: (was: 2.0.0)
> Error while rolling update from Kafka Streams 2.0.0 -> Kafka Streams 2.1.0
> --
>
> Key: KAFKA-8649
> URL: https://issues.apache.org/jira/browse/KAFKA-8649
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 2.0.0
>Reporter: Suyash Garg
>Priority: Major
>
> While doing a rolling update of a cluster of nodes running Kafka Streams
> application, the stream threads in the nodes running the old version of the
> library (2.0.0), fail with the following error:
> {code:java}
> [ERROR] [application-existing-StreamThread-336]
> [o.a.k.s.p.internals.StreamThread] - stream-thread
> [application-existing-StreamThread-336] Encountered the following error
> during processing:
> java.lang.IllegalArgumentException: version must be between 1 and 3; was: 4
> #011at
> org.apache.kafka.streams.processor.internals.assignment.SubscriptionInfo.(SubscriptionInfo.java:67)
> #011at
> org.apache.kafka.streams.processor.internals.StreamsPartitionAssignor.subscription(StreamsPartitionAssignor.java:312)
> #011at
> org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.metadata(ConsumerCoordinator.java:176)
> #011at
> org.apache.kafka.clients.consumer.internals.AbstractCoordinator.sendJoinGroupRequest(AbstractCoordinator.java:515)
> #011at
> org.apache.kafka.clients.consumer.internals.AbstractCoordinator.initiateJoinGroup(AbstractCoordinator.java:466)
> #011at
> org.apache.kafka.clients.consumer.internals.AbstractCoordinator.joinGroupIfNeeded(AbstractCoordinator.java:412)
> #011at
> org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:352)
> #011at
> org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:337)
> #011at
> org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.poll(ConsumerCoordinator.java:333)
> #011at
> org.apache.kafka.clients.consumer.KafkaConsumer.updateAssignmentMetadataIfNeeded(KafkaConsumer.java:1218)
> #011at
> org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1175)
> #011at
> org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1154)
> #011at
> org.apache.kafka.streams.processor.internals.StreamThread.pollRequests(StreamThread.java:861)
> #011at
> org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:814)
> #011at
> org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:767)
> #011at
> org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:736)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-8233) Helper classes to make it simpler to write test logic with TopologyTestDriver
[ https://issues.apache.org/jira/browse/KAFKA-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936337#comment-16936337 ] Matthias J. Sax commented on KAFKA-8233: [~jkarvanen] – I added you to the list of contributors and assigned the ticket to you. You can now also self-assign ticket. > Helper classes to make it simpler to write test logic with TopologyTestDriver > - > > Key: KAFKA-8233 > URL: https://issues.apache.org/jira/browse/KAFKA-8233 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Jukka Karvanen >Assignee: Jukka Karvanen >Priority: Minor > Labels: kip > > When using TopologyTestDriver you need to call ConsumerRecordFactory to > create ConsumerRecord passed into pipeInput method to write to topic. Also > when calling readOutput to consume from topic, you need to provide correct > Deserializers each time. > You easily end up writing helper methods in your test classed, but this can > be avoided when adding generic input and output topic classes. > This improvement adds TestInputTopic class which wraps TopologyTestDriver > and ConsumerRecordFactory methods as one class to be used to write to Input > Topics and TestOutputTopic class which collects TopologyTestDriver reading > methods and provide typesafe read methods. > This is KIP: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-470%3A+TopologyTestDriver+test+input+and+output+usability+improvements] > > > More info and an example of how Stream test looks after using this classes: > [https://github.com/jukkakarvanen/kafka-streams-test-topics] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KAFKA-8233) Helper classes to make it simpler to write test logic with TopologyTestDriver
[ https://issues.apache.org/jira/browse/KAFKA-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax reassigned KAFKA-8233: -- Assignee: Jukka Karvanen > Helper classes to make it simpler to write test logic with TopologyTestDriver > - > > Key: KAFKA-8233 > URL: https://issues.apache.org/jira/browse/KAFKA-8233 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Jukka Karvanen >Assignee: Jukka Karvanen >Priority: Minor > Labels: kip > > When using TopologyTestDriver you need to call ConsumerRecordFactory to > create ConsumerRecord passed into pipeInput method to write to topic. Also > when calling readOutput to consume from topic, you need to provide correct > Deserializers each time. > You easily end up writing helper methods in your test classed, but this can > be avoided when adding generic input and output topic classes. > This improvement adds TestInputTopic class which wraps TopologyTestDriver > and ConsumerRecordFactory methods as one class to be used to write to Input > Topics and TestOutputTopic class which collects TopologyTestDriver reading > methods and provide typesafe read methods. > This is KIP: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-470%3A+TopologyTestDriver+test+input+and+output+usability+improvements] > > > More info and an example of how Stream test looks after using this classes: > [https://github.com/jukkakarvanen/kafka-streams-test-topics] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-8233) Helper classes to make it simpler to write test logic with TopologyTestDriver
[ https://issues.apache.org/jira/browse/KAFKA-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax updated KAFKA-8233: --- Labels: kip (was: needs-kip) > Helper classes to make it simpler to write test logic with TopologyTestDriver > - > > Key: KAFKA-8233 > URL: https://issues.apache.org/jira/browse/KAFKA-8233 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Jukka Karvanen >Priority: Minor > Labels: kip > > When using TopologyTestDriver you need to call ConsumerRecordFactory to > create ConsumerRecord passed into pipeInput method to write to topic. Also > when calling readOutput to consume from topic, you need to provide correct > Deserializers each time. > You easily end up writing helper methods in your test classed, but this can > be avoided when adding generic input and output topic classes. > This improvement adds TestInputTopic class which wraps TopologyTestDriver > and ConsumerRecordFactory methods as one class to be used to write to Input > Topics and TestOutputTopic class which collects TopologyTestDriver reading > methods and provide typesafe read methods. > This is KIP: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-470%3A+TopologyTestDriver+test+input+and+output+usability+improvements] > > > More info and an example of how Stream test looks after using this classes: > [https://github.com/jukkakarvanen/kafka-streams-test-topics] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-8613) Set default grace period to 0
[
https://issues.apache.org/jira/browse/KAFKA-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936335#comment-16936335
]
Matthias J. Sax commented on KAFKA-8613:
I think the tricky part is expected default behavior for an aggregation itself
and the difference in what might be better default behavior with and without
suppress. Originally, we only had retention time and set it to 24h to allow
handling out-of-order records out-of-the-box.
Thinking about it more, this previous decision might not have been the best
one. If we would have set retention time to zero by default, and hence force
people to opt-in for longer retention time and thus opt-in to handle
out-of-order data, it might have been better (also consider the required
storage to store 24h worth of data). Note that seems to be quite consistent
with regard to windowed vs non-windowed aggregation, too. There is also not
good justification to pick 24h as default value (why not 7days? why not 12h? or
just 1h?).
>From an API point of view, it seem undesirable to throw a runtime exception
>though. And it might also be undesired to have different behavior with and
>without suppress...
Overall, I think we have two options:
# set default grace period and default retention time to zero
# make grace period a mandatory argument (enforce by the API, ie, not runtime
exception)
I think that (1) has the big disadvantage that we advertise Kafka Streams as
"can handle out-of-order data" but we force users to opt-in. For (2), the
disadvantage is that we force people to think about it, ie, we "violate" the
idea to keep the API as simple as possible.
Given the current confusion about suppress(), atm I tend to think that (1) is
the slightly better option.
What we should not do, from my point of view:
* throw runtime exceptions
* have different default (windowed vs non-windowed and with/without suppress)
Thoughts?
> Set default grace period to 0
> -
>
> Key: KAFKA-8613
> URL: https://issues.apache.org/jira/browse/KAFKA-8613
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: Bruno Cadonna
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently, the grace period is set to retention time if the grace period is
> not specified explicitly. The reason for setting the default grace period to
> retention time was backward compatibility. Topologies that were implemented
> before the introduction of the grace period, added late arriving records to a
> window as long as the window existed, i.e., as long as its retention time was
> not elapsed.
> This unintuitive default grace period has already caused confusion among
> users.
> For the next major release, we should set the default grace period to
> {{Duration.ZERO}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-8233) Helper classes to make it simpler to write test logic with TopologyTestDriver
[ https://issues.apache.org/jira/browse/KAFKA-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936322#comment-16936322 ] ASF GitHub Bot commented on KAFKA-8233: --- jukkakarvanen commented on pull request #7378: KAFKA-8233: [WIP] KIP-470: TopologyTestDriver test input and output usability improvements URL: https://github.com/apache/kafka/pull/7378 This is WIP PR for KIP-470: TopologyTestDriver test input and output usability improvements: https://cwiki.apache.org/confluence/display/KAFKA/KIP-470%3A+TopologyTestDriver+test+input+and+output+usability+improvements Implementation mainly done. Still to do: -Check unit test coverage -Update example application -Update documentation ### Committer Checklist (excluded from commit message) - [ ] Verify design and implementation - [ ] Verify test coverage and CI build status - [ ] Verify documentation (including upgrade notes) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Helper classes to make it simpler to write test logic with TopologyTestDriver > - > > Key: KAFKA-8233 > URL: https://issues.apache.org/jira/browse/KAFKA-8233 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Jukka Karvanen >Priority: Minor > Labels: needs-kip > > When using TopologyTestDriver you need to call ConsumerRecordFactory to > create ConsumerRecord passed into pipeInput method to write to topic. Also > when calling readOutput to consume from topic, you need to provide correct > Deserializers each time. > You easily end up writing helper methods in your test classed, but this can > be avoided when adding generic input and output topic classes. > This improvement adds TestInputTopic class which wraps TopologyTestDriver > and ConsumerRecordFactory methods as one class to be used to write to Input > Topics and TestOutputTopic class which collects TopologyTestDriver reading > methods and provide typesafe read methods. > This is KIP: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-470%3A+TopologyTestDriver+test+input+and+output+usability+improvements] > > > More info and an example of how Stream test looks after using this classes: > [https://github.com/jukkakarvanen/kafka-streams-test-topics] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-8233) Helper classes to make it simpler to write test logic with TopologyTestDriver
[ https://issues.apache.org/jira/browse/KAFKA-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Karvanen updated KAFKA-8233: -- Description: When using TopologyTestDriver you need to call ConsumerRecordFactory to create ConsumerRecord passed into pipeInput method to write to topic. Also when calling readOutput to consume from topic, you need to provide correct Deserializers each time. You easily end up writing helper methods in your test classed, but this can be avoided when adding generic input and output topic classes. This improvement adds TestInputTopic class which wraps TopologyTestDriver and ConsumerRecordFactory methods as one class to be used to write to Input Topics and TestOutputTopic class which collects TopologyTestDriver reading methods and provide typesafe read methods. This is KIP: [https://cwiki.apache.org/confluence/display/KAFKA/KIP-470%3A+TopologyTestDriver+test+input+and+output+usability+improvements] More info and an example of how Stream test looks after using this classes: [https://github.com/jukkakarvanen/kafka-streams-test-topics] was: When using TopologyTestDriver you need to call ConsumerRecordFactory to create ConsumerRecord passed into pipeInput method to write to topic. Also when calling readOutput to consume from topic, you need to provide correct Deserializers each time. You easily end up writing helper methods in your test classed, but this can be avoided when adding generic input and output topic classes. This improvement adds TestInputTopic class which wraps TopologyTestDriver and ConsumerRecordFactory methods as one class to be used to write to Input Topics and TestOutputTopic class which collects TopologyTestDriver reading methods and provide typesafe read methods. More info and an example of how Stream test looks after using this classes: [https://github.com/jukkakarvanen/kafka-streams-test-topics] Summary: Helper classes to make it simpler to write test logic with TopologyTestDriver (was: Helper class to make it simpler to write test logic with TopologyTestDriver) > Helper classes to make it simpler to write test logic with TopologyTestDriver > - > > Key: KAFKA-8233 > URL: https://issues.apache.org/jira/browse/KAFKA-8233 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Jukka Karvanen >Priority: Minor > Labels: needs-kip > > When using TopologyTestDriver you need to call ConsumerRecordFactory to > create ConsumerRecord passed into pipeInput method to write to topic. Also > when calling readOutput to consume from topic, you need to provide correct > Deserializers each time. > You easily end up writing helper methods in your test classed, but this can > be avoided when adding generic input and output topic classes. > This improvement adds TestInputTopic class which wraps TopologyTestDriver > and ConsumerRecordFactory methods as one class to be used to write to Input > Topics and TestOutputTopic class which collects TopologyTestDriver reading > methods and provide typesafe read methods. > This is KIP: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-470%3A+TopologyTestDriver+test+input+and+output+usability+improvements] > > > More info and an example of how Stream test looks after using this classes: > [https://github.com/jukkakarvanen/kafka-streams-test-topics] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-8931) PR '#6850' fix issue 'KAFKA-8449', but lead to restart all cached tasks, which conflict to the motivation of incremental cooperative rebalancing.
[
https://issues.apache.org/jira/browse/KAFKA-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936293#comment-16936293
]
HeryLong commented on KAFKA-8931:
-
Hi [~kkonstantine]:
Please see the following log, we just log the variable `updatedTasks` at
[KafkaConfigBackingStore.java#L637|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/storage/KafkaConfigBackingStore.java#L637]
before `updateListener.onTaskConfigUpdate(updatedTasks);` , which will be
restart next.
The first time, we add a new connector named
`mysql__loghub_deve_mysql_d8_1_11568272307638` with `tasks.max=1`, the log is:
{code:java}
[2019-09-12 15:11:49,946] INFO yllu2
deferred={mysql__loghub_deve_mysql_d8_1_11568272307638-0={connector.class=io.debezium.connector.mysql.MySqlConnector,
database.user=root, database.server.id=223396,
database.history.kafka.bootstrap.servers=172.31.96.165:9092,172.31.96.166:9092,172.31.96.167:9092,
database.history.kafka.topic=loghub_deve_mysql_d8_1_11568272307638.schema.changes,
database.server.name=loghub_deve_mysql_d8_1_11568272307638,
include.schema.changes=true, database.port=3306,
table.whitelist=inventory.tunnel_monitor_record,
key.converter.schemas.enable=true,
task.class=io.debezium.connector.mysql.MySqlConnectorTask,
snapshot.new.tables=parallel, database.hostname=172.31.96.165,
database.password=debezium, value.converter.schemas.enable=true,
name=mysql__loghub_deve_mysql_d8_1_11568272307638,
database.blacklist=mysql,information_schema,performance_schema,
value.converter=org.apache.kafka.connect.json.JsonConverter,
key.converter=org.apache.kafka.connect.json.JsonConverter}},
taskConfigs.keySet=[mysql__loghub_deve_mysql_d6_2_21568259412646-0,
mysql__loghub_deve_mysql_d5_1_11568197168903-0,
mysql__loghub_deve_mysql_d5_1_21568197168903-0,
mysql__loghub_deve_mysql_d3_1_21568197168903-0,
mysql__loghub_deve_mysql_d6_1_21568258962192-0,
mysql__loghub_deve_mysql_d4_1_21568253242922-0,
mysql__loghub_deve_mysql_dd_1_1156819702-0,
mysql__loghub_deve_mysql_d3_1_11568197168903-0,
mysql__loghub_deve_mysql_d4_1_11568253194763-0,
mysql__loghub_deve_mysql_d6_1_11568258162071-0,
mysql__loghub_deve_mysql_dd_1_21568197168903-0,
mysql__loghub_deve_mysql_d7_1_21568271676731-0,
mysql__loghub_deve_mysql_d7_1_11568271070252-0]
(org.apache.kafka.connect.storage.KafkaConfigBackingStore:623)
[2019-09-12 15:11:49,947] INFO yllu2 started
updateListener.onTaskConfigUpdate=[mysql__loghub_deve_mysql_d6_2_21568259412646-0,
mysql__loghub_deve_mysql_d5_1_11568197168903-0,
mysql__loghub_deve_mysql_d5_1_21568197168903-0,
mysql__loghub_deve_mysql_d3_1_21568197168903-0,
mysql__loghub_deve_mysql_d6_1_21568258962192-0,
mysql__loghub_deve_mysql_d4_1_21568253242922-0,
mysql__loghub_deve_mysql_d8_1_11568272307638-0,
mysql__loghub_deve_mysql_dd_1_1156819702-0,
mysql__loghub_deve_mysql_d3_1_11568197168903-0,
mysql__loghub_deve_mysql_d4_1_11568253194763-0,
mysql__loghub_deve_mysql_d6_1_11568258162071-0,
mysql__loghub_deve_mysql_dd_1_21568197168903-0,
mysql__loghub_deve_mysql_d7_1_21568271676731-0,
mysql__loghub_deve_mysql_d7_1_11568271070252-0]
(org.apache.kafka.connect.storage.KafkaConfigBackingStore:642)
{code}
You can see, task `mysql__loghub_deve_mysql_d8_1_11568272307638-0` is in the
variable `updatedTasks`, and will be restart functionally, the other
connectorTasks are the undetected side-effect of: KAFKA-8869 as your mentioned
before;
Secondly, we add another new connector named
`mysql__loghub_deve_mysql_d8_1_21568272331420`, with `tasks.max=1' also, the
log is:
{code:java}
[2019-09-12 15:12:12,782] INFO yllu2
deferred={mysql__loghub_deve_mysql_d8_1_21568272331420-0={connector.class=io.debezium.connector.mysql.MySqlConnector,
database.user=root, database.server.id=223397,
database.history.kafka.bootstrap.servers=172.31.96.165:9092,172.31.96.166:9092,172.31.96.167:9092,
database.history.kafka.topic=loghub_deve_mysql_d8_1_21568272331420.schema.changes,
database.server.name=loghub_deve_mysql_d8_1_21568272331420,
include.schema.changes=true, database.port=3307,
table.whitelist=inventory.addresses, key.converter.schemas.enable=true,
task.class=io.debezium.connector.mysql.MySqlConnectorTask,
snapshot.new.tables=parallel, database.hostname=172.31.96.165,
database.password=debezium, value.converter.schemas.enable=true,
name=mysql__loghub_deve_mysql_d8_1_21568272331420,
database.blacklist=mysql,information_schema,performance_schema,
value.converter=org.apache.kafka.connect.json.JsonConverter,
key.converter=org.apache.kafka.connect.json.JsonConverter}},
taskConfigs.keySet=[mysql__loghub_deve_mysql_d6_2_21568259412646-0,
mysql__loghub_deve_mysql_d5_1_11568197168903-0,
mysql__loghub_deve_mysql_d5_1_21568197168903-0,
mysql__loghub_deve_mysql_d3_1_21568197168903-0,
mysql__loghub_deve_mysql_d6_1_21568258962192-0,
[jira] [Commented] (KAFKA-8931) PR '#6850' fix issue 'KAFKA-8449', but lead to restart all cached tasks, which conflict to the motivation of incremental cooperative rebalancing.
[ https://issues.apache.org/jira/browse/KAFKA-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936251#comment-16936251 ] Konstantine Karantasis commented on KAFKA-8931: --- Hi [~HeryLong], thanks for reporting on this. When a connector get reconfigured all its tasks need to restart to make sure that they read the new updated configuration. I'm not sure to which tasks you are referring to as "cached" here. Are you observing a yet undetected side-effect of: https://issues.apache.org/jira/browse/KAFKA-8869 somehow? Clarifying which tasks you see getting restarted and what you'd expect with an example, might help us get on the same page regarding this issue. Thanks > PR '#6850' fix issue 'KAFKA-8449', but lead to restart all cached tasks, > which conflict to the motivation of incremental cooperative rebalancing. > -- > > Key: KAFKA-8931 > URL: https://issues.apache.org/jira/browse/KAFKA-8931 > Project: Kafka > Issue Type: Bug > Components: KafkaConnect >Affects Versions: 2.3.0 >Reporter: HeryLong >Priority: Blocker > Attachments: > 0001-just-restart-current-reconfigurated-connectorTask-no-all-cacheds-ones.patch > > > Recently, we are testing Kafka Connect 2.3.0, checking the incremental > cooperative rebalancing mechanism. > > We found that when new connector was putted via REST endpoint, Kafka Connect > 2.3.0 will restart all cached tasks; > And the issuse is 'KAFKA-8449', the PR is > '[#6850|https://github.com/apache/kafka/pull/6850]'; > > So, the result is, new connector putted will lead to all cached tasks > restarted, which conflict to the motivation of incremental cooperative > rebalancing. > > Should it just restart the new reconfigurated connector or tasks, not all > cached ones? > And I have made a PR, please check it out, > '[#7348|https://github.com/apache/kafka/pull/7348]' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-8613) Set default grace period to 0
[
https://issues.apache.org/jira/browse/KAFKA-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936225#comment-16936225
]
Bruno Cadonna commented on KAFKA-8613:
--
Hi [~vvcephei],
I might have been focusing too much on the suppress case when I opened this
ticket. Thinking about it again, I would still expect the grace period to be 0
if I do not specify anything. Any other default value I would need to remember.
Making grace period required would also be fine because it better document the
Streams app, IMO.
> Set default grace period to 0
> -
>
> Key: KAFKA-8613
> URL: https://issues.apache.org/jira/browse/KAFKA-8613
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: Bruno Cadonna
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently, the grace period is set to retention time if the grace period is
> not specified explicitly. The reason for setting the default grace period to
> retention time was backward compatibility. Topologies that were implemented
> before the introduction of the grace period, added late arriving records to a
> window as long as the window existed, i.e., as long as its retention time was
> not elapsed.
> This unintuitive default grace period has already caused confusion among
> users.
> For the next major release, we should set the default grace period to
> {{Duration.ZERO}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-8613) Set default grace period to 0
[
https://issues.apache.org/jira/browse/KAFKA-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936172#comment-16936172
]
John Roesler commented on KAFKA-8613:
-
Hey [~cadonna],
I just learned of this ticket from the mention on KAFKA-8924. I initially
shared this viewpoint, but recently, I've started to wonder if `0` is actually
the right default grace period. It would mean that Streams by default would not
process late records (out-of-order data arriving after the window end) at all.
I believe the only instance in which our current default has been confusing is
when folks use Suppress in conjunction with the default grace period. Maybe we
can find a good, direct solution to that problem (like requiring an explicit
grace period when using Suppress) rather than dropping all late records for all
windowed aggregations.
Then again, you might have some other reason in mind to change the default. Can
you comment on the rationale?
Thanks,
-John
> Set default grace period to 0
> -
>
> Key: KAFKA-8613
> URL: https://issues.apache.org/jira/browse/KAFKA-8613
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: Bruno Cadonna
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently, the grace period is set to retention time if the grace period is
> not specified explicitly. The reason for setting the default grace period to
> retention time was backward compatibility. Topologies that were implemented
> before the introduction of the grace period, added late arriving records to a
> window as long as the window existed, i.e., as long as its retention time was
> not elapsed.
> This unintuitive default grace period has already caused confusion among
> users.
> For the next major release, we should set the default grace period to
> {{Duration.ZERO}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-7026) Sticky assignor could assign a partition to multiple consumers (KIP-341)
[
https://issues.apache.org/jira/browse/KAFKA-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936147#comment-16936147
]
Vahid Hashemian commented on KAFKA-7026:
[~redbrick9] Can you please provide detailed steps to reproduce? Thanks!
> Sticky assignor could assign a partition to multiple consumers (KIP-341)
>
>
> Key: KAFKA-7026
> URL: https://issues.apache.org/jira/browse/KAFKA-7026
> Project: Kafka
> Issue Type: Bug
> Components: clients
>Reporter: Vahid Hashemian
>Assignee: Vahid Hashemian
>Priority: Major
> Labels: kip
> Fix For: 2.3.0
>
>
> In the following scenario sticky assignor assigns a topic partition to two
> consumers in the group:
> # Create a topic {{test}} with a single partition
> # Start consumer {{c1}} in group {{sticky-group}} ({{c1}} becomes group
> leader and gets {{test-0}})
> # Start consumer {{c2}} in group {{sticky-group}} ({{c1}} holds onto
> {{test-0}}, {{c2}} does not get any partition)
> # Pause {{c1}} (e.g. using Java debugger) ({{c2}} becomes leader and takes
> over {{test-0}}, {{c1}} leaves the group)
> # Resume {{c1}}
> At this point both {{c1}} and {{c2}} will have {{test-0}} assigned to them.
>
> The reason is {{c1}} still has kept its previous assignment ({{test-0}}) from
> the last assignment it received from the leader (itself) and did not get the
> next round of assignments (when {{c2}} became leader) because it was paused.
> Both {{c1}} and {{c2}} enter the rebalance supplying {{test-0}} as their
> existing assignment. The sticky assignor code does not currently check and
> avoid this duplication.
>
> Note: This issue was originally reported on
> [StackOverflow|https://stackoverflow.com/questions/50761842/kafka-stickyassignor-breaking-delivery-to-single-consumer-in-the-group].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-6958) Allow to define custom processor names with KStreams DSL
[ https://issues.apache.org/jira/browse/KAFKA-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936044#comment-16936044 ] ASF GitHub Bot commented on KAFKA-6958: --- bbejeck commented on pull request #6413: KAFKA-6958: Overload methods for group and windowed stream to allow to name operation name using the new Named class URL: https://github.com/apache/kafka/pull/6413 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow to define custom processor names with KStreams DSL > > > Key: KAFKA-6958 > URL: https://issues.apache.org/jira/browse/KAFKA-6958 > Project: Kafka > Issue Type: Improvement > Components: streams >Affects Versions: 1.1.0 >Reporter: Florian Hussonnois >Assignee: Florian Hussonnois >Priority: Minor > Labels: kip > > Currently, while building a new Topology through the KStreams DSL the > processors are automatically named. > The genarated names are prefixed depending of the operation (i.e > KSTREAM-SOURCE, KSTREAM-FILTER, KSTREAM-MAP, etc). > To debug/understand a topology it is possible to display the processor > lineage with the method Topology#describe(). However, a complex topology with > dozens of operations can be hard to understand if the processor names are not > relevant. > It would be useful to be able to set more meaningful names. For example, a > processor name could describe the business rule performed by a map() > operation. > [KIP-307|https://cwiki.apache.org/confluence/display/KAFKA/KIP-307%3A+Allow+to+define+custom+processor+names+with+KStreams+DSL] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (KAFKA-8086) Flaky Test GroupAuthorizerIntegrationTest#testPatternSubscriptionWithTopicAndGroupRead
[
https://issues.apache.org/jira/browse/KAFKA-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guozhang Wang resolved KAFKA-8086.
--
Resolution: Fixed
> Flaky Test
> GroupAuthorizerIntegrationTest#testPatternSubscriptionWithTopicAndGroupRead
> --
>
> Key: KAFKA-8086
> URL: https://issues.apache.org/jira/browse/KAFKA-8086
> Project: Kafka
> Issue Type: Bug
> Components: admin, unit tests
>Affects Versions: 2.2.0
>Reporter: Matthias J. Sax
>Priority: Critical
> Labels: flaky-test
> Fix For: 2.4.0
>
>
> [https://jenkins.confluent.io/job/apache-kafka-test/job/2.2/62/testReport/junit/kafka.api/GroupAuthorizerIntegrationTest/testPatternSubscriptionWithTopicAndGroupRead/]
> {quote}java.lang.AssertionError: Partition [__consumer_offsets,0] metadata
> not propagated after 15000 ms at
> kafka.utils.TestUtils$.fail(TestUtils.scala:381) at
> kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:791) at
> kafka.utils.TestUtils$.waitUntilMetadataIsPropagated(TestUtils.scala:880) at
> kafka.utils.TestUtils$.$anonfun$createTopic$3(TestUtils.scala:318) at
> kafka.utils.TestUtils$.$anonfun$createTopic$3$adapted(TestUtils.scala:317) at
> scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:237) at
> scala.collection.immutable.Range.foreach(Range.scala:158) at
> scala.collection.TraversableLike.map(TraversableLike.scala:237) at
> scala.collection.TraversableLike.map$(TraversableLike.scala:230) at
> scala.collection.AbstractTraversable.map(Traversable.scala:108) at
> kafka.utils.TestUtils$.createTopic(TestUtils.scala:317) at
> kafka.utils.TestUtils$.createOffsetsTopic(TestUtils.scala:375) at
> kafka.api.AuthorizerIntegrationTest.setUp(AuthorizerIntegrationTest.scala:242){quote}
> STDOUT
> {quote}[2019-03-09 08:40:34,220] ERROR [KafkaApi-0] Error when handling
> request: clientId=0, correlationId=0, api=UPDATE_METADATA,
> body=\{controller_id=0,controller_epoch=1,broker_epoch=25,topic_states=[],live_brokers=[{id=0,end_points=[{port=41020,host=localhost,listener_name=PLAINTEXT,security_protocol_type=0}],rack=null}]}
> (kafka.server.KafkaApis:76)
> org.apache.kafka.common.errors.ClusterAuthorizationException: Request
> Request(processor=0, connectionId=127.0.0.1:41020-127.0.0.1:52304-0,
> session=Session(Group:testGroup,/127.0.0.1),
> listenerName=ListenerName(PLAINTEXT), securityProtocol=PLAINTEXT,
> buffer=null) is not authorized. [2019-03-09 08:40:35,336] ERROR [Consumer
> clientId=consumer-98, groupId=my-group] Offset commit failed on partition
> topic-0 at offset 5: Not authorized to access topics: [Topic authorization
> failed.]
> (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator:812)
> [2019-03-09 08:40:35,336] ERROR [Consumer clientId=consumer-98,
> groupId=my-group] Not authorized to commit to topics [topic]
> (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator:850)
> [2019-03-09 08:40:41,649] ERROR [KafkaApi-0] Error when handling request:
> clientId=0, correlationId=0, api=UPDATE_METADATA,
> body=\{controller_id=0,controller_epoch=1,broker_epoch=25,topic_states=[],live_brokers=[{id=0,end_points=[{port=36903,host=localhost,listener_name=PLAINTEXT,security_protocol_type=0}],rack=null}]}
> (kafka.server.KafkaApis:76)
> org.apache.kafka.common.errors.ClusterAuthorizationException: Request
> Request(processor=0, connectionId=127.0.0.1:36903-127.0.0.1:44978-0,
> session=Session(Group:testGroup,/127.0.0.1),
> listenerName=ListenerName(PLAINTEXT), securityProtocol=PLAINTEXT,
> buffer=null) is not authorized. [2019-03-09 08:40:53,898] ERROR [KafkaApi-0]
> Error when handling request: clientId=0, correlationId=0,
> api=UPDATE_METADATA,
> body=\{controller_id=0,controller_epoch=1,broker_epoch=25,topic_states=[],live_brokers=[{id=0,end_points=[{port=41067,host=localhost,listener_name=PLAINTEXT,security_protocol_type=0}],rack=null}]}
> (kafka.server.KafkaApis:76)
> org.apache.kafka.common.errors.ClusterAuthorizationException: Request
> Request(processor=0, connectionId=127.0.0.1:41067-127.0.0.1:40882-0,
> session=Session(Group:testGroup,/127.0.0.1),
> listenerName=ListenerName(PLAINTEXT), securityProtocol=PLAINTEXT,
> buffer=null) is not authorized. [2019-03-09 08:42:07,717] ERROR [KafkaApi-0]
> Error when handling request: clientId=0, correlationId=0,
> api=UPDATE_METADATA,
> body=\{controller_id=0,controller_epoch=1,broker_epoch=25,topic_states=[],live_brokers=[{id=0,end_points=[{port=46276,host=localhost,listener_name=PLAINTEXT,security_protocol_type=0}],rack=null}]}
> (kafka.server.KafkaApis:76)
> org.apache.kafka.common.errors.ClusterAuthorizationException: Request
> Request(processor=0, connectionId=127.0.0.1:46276-127.0.0.1:41362-0,
>
[jira] [Commented] (KAFKA-8086) Flaky Test GroupAuthorizerIntegrationTest#testPatternSubscriptionWithTopicAndGroupRead
[
https://issues.apache.org/jira/browse/KAFKA-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936008#comment-16936008
]
ASF GitHub Bot commented on KAFKA-8086:
---
guozhangwang commented on pull request #7356: KAFKA-8086: Use 1 partition for
offset topic when possible
URL: https://github.com/apache/kafka/pull/7356
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Flaky Test
> GroupAuthorizerIntegrationTest#testPatternSubscriptionWithTopicAndGroupRead
> --
>
> Key: KAFKA-8086
> URL: https://issues.apache.org/jira/browse/KAFKA-8086
> Project: Kafka
> Issue Type: Bug
> Components: admin, unit tests
>Affects Versions: 2.2.0
>Reporter: Matthias J. Sax
>Priority: Critical
> Labels: flaky-test
> Fix For: 2.4.0
>
>
> [https://jenkins.confluent.io/job/apache-kafka-test/job/2.2/62/testReport/junit/kafka.api/GroupAuthorizerIntegrationTest/testPatternSubscriptionWithTopicAndGroupRead/]
> {quote}java.lang.AssertionError: Partition [__consumer_offsets,0] metadata
> not propagated after 15000 ms at
> kafka.utils.TestUtils$.fail(TestUtils.scala:381) at
> kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:791) at
> kafka.utils.TestUtils$.waitUntilMetadataIsPropagated(TestUtils.scala:880) at
> kafka.utils.TestUtils$.$anonfun$createTopic$3(TestUtils.scala:318) at
> kafka.utils.TestUtils$.$anonfun$createTopic$3$adapted(TestUtils.scala:317) at
> scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:237) at
> scala.collection.immutable.Range.foreach(Range.scala:158) at
> scala.collection.TraversableLike.map(TraversableLike.scala:237) at
> scala.collection.TraversableLike.map$(TraversableLike.scala:230) at
> scala.collection.AbstractTraversable.map(Traversable.scala:108) at
> kafka.utils.TestUtils$.createTopic(TestUtils.scala:317) at
> kafka.utils.TestUtils$.createOffsetsTopic(TestUtils.scala:375) at
> kafka.api.AuthorizerIntegrationTest.setUp(AuthorizerIntegrationTest.scala:242){quote}
> STDOUT
> {quote}[2019-03-09 08:40:34,220] ERROR [KafkaApi-0] Error when handling
> request: clientId=0, correlationId=0, api=UPDATE_METADATA,
> body=\{controller_id=0,controller_epoch=1,broker_epoch=25,topic_states=[],live_brokers=[{id=0,end_points=[{port=41020,host=localhost,listener_name=PLAINTEXT,security_protocol_type=0}],rack=null}]}
> (kafka.server.KafkaApis:76)
> org.apache.kafka.common.errors.ClusterAuthorizationException: Request
> Request(processor=0, connectionId=127.0.0.1:41020-127.0.0.1:52304-0,
> session=Session(Group:testGroup,/127.0.0.1),
> listenerName=ListenerName(PLAINTEXT), securityProtocol=PLAINTEXT,
> buffer=null) is not authorized. [2019-03-09 08:40:35,336] ERROR [Consumer
> clientId=consumer-98, groupId=my-group] Offset commit failed on partition
> topic-0 at offset 5: Not authorized to access topics: [Topic authorization
> failed.]
> (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator:812)
> [2019-03-09 08:40:35,336] ERROR [Consumer clientId=consumer-98,
> groupId=my-group] Not authorized to commit to topics [topic]
> (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator:850)
> [2019-03-09 08:40:41,649] ERROR [KafkaApi-0] Error when handling request:
> clientId=0, correlationId=0, api=UPDATE_METADATA,
> body=\{controller_id=0,controller_epoch=1,broker_epoch=25,topic_states=[],live_brokers=[{id=0,end_points=[{port=36903,host=localhost,listener_name=PLAINTEXT,security_protocol_type=0}],rack=null}]}
> (kafka.server.KafkaApis:76)
> org.apache.kafka.common.errors.ClusterAuthorizationException: Request
> Request(processor=0, connectionId=127.0.0.1:36903-127.0.0.1:44978-0,
> session=Session(Group:testGroup,/127.0.0.1),
> listenerName=ListenerName(PLAINTEXT), securityProtocol=PLAINTEXT,
> buffer=null) is not authorized. [2019-03-09 08:40:53,898] ERROR [KafkaApi-0]
> Error when handling request: clientId=0, correlationId=0,
> api=UPDATE_METADATA,
> body=\{controller_id=0,controller_epoch=1,broker_epoch=25,topic_states=[],live_brokers=[{id=0,end_points=[{port=41067,host=localhost,listener_name=PLAINTEXT,security_protocol_type=0}],rack=null}]}
> (kafka.server.KafkaApis:76)
> org.apache.kafka.common.errors.ClusterAuthorizationException: Request
> Request(processor=0, connectionId=127.0.0.1:41067-127.0.0.1:40882-0,
> session=Session(Group:testGroup,/127.0.0.1),
> listenerName=ListenerName(PLAINTEXT), securityProtocol=PLAINTEXT,
> buffer=null) is not authorized. [2019-03-09 08:42:07,717] ERROR
[jira] [Commented] (KAFKA-8896) NoSuchElementException after coordinator move
[
https://issues.apache.org/jira/browse/KAFKA-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935998#comment-16935998
]
ASF GitHub Bot commented on KAFKA-8896:
---
abbccdda commented on pull request #7377: KAFKA-8896: Check group state before
completing delayed heartbeat
URL: https://github.com/apache/kafka/pull/7377
This PR is a defensive fix for reported bug 8896, which would cause group
coordinator crash when the heartbeat member was not found.
### Committer Checklist (excluded from commit message)
- [ ] Verify design and implementation
- [ ] Verify test coverage and CI build status
- [ ] Verify documentation (including upgrade notes)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> NoSuchElementException after coordinator move
> -
>
> Key: KAFKA-8896
> URL: https://issues.apache.org/jira/browse/KAFKA-8896
> Project: Kafka
> Issue Type: Bug
>Reporter: Jason Gustafson
>Assignee: Boyang Chen
>Priority: Major
>
> Caught this exception in the wild:
> {code:java}
> java.util.NoSuchElementException: key not found:
> consumer-group-38981ebe-4361-44e7-b710-7d11f5d35639
> at scala.collection.MapLike.default(MapLike.scala:235)
> at scala.collection.MapLike.default$(MapLike.scala:234)
> at scala.collection.AbstractMap.default(Map.scala:63)
> at scala.collection.mutable.HashMap.apply(HashMap.scala:69)
> at kafka.coordinator.group.GroupMetadata.get(GroupMetadata.scala:214)
> at
> kafka.coordinator.group.GroupCoordinator.$anonfun$tryCompleteHeartbeat$1(GroupCoordinator.scala:1008)
> at
> scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:253)
> at kafka.coordinator.group.GroupMetadata.inLock(GroupMetadata.scala:209)
> at
> kafka.coordinator.group.GroupCoordinator.tryCompleteHeartbeat(GroupCoordinator.scala:1001)
> at
> kafka.coordinator.group.DelayedHeartbeat.tryComplete(DelayedHeartbeat.scala:34)
> at
> kafka.server.DelayedOperation.maybeTryComplete(DelayedOperation.scala:122)
> at
> kafka.server.DelayedOperationPurgatory$Watchers.tryCompleteWatched(DelayedOperation.scala:391)
> at
> kafka.server.DelayedOperationPurgatory.checkAndComplete(DelayedOperation.scala:295)
> at
> kafka.coordinator.group.GroupCoordinator.completeAndScheduleNextExpiration(GroupCoordinator.scala:802)
> at
> kafka.coordinator.group.GroupCoordinator.completeAndScheduleNextHeartbeatExpiration(GroupCoordinator.scala:795)
> at
> kafka.coordinator.group.GroupCoordinator.$anonfun$handleHeartbeat$2(GroupCoordinator.scala:543)
> at
> scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:253)
> at kafka.coordinator.group.GroupMetadata.inLock(GroupMetadata.scala:209)
> at
> kafka.coordinator.group.GroupCoordinator.handleHeartbeat(GroupCoordinator.scala:516)
> at kafka.server.KafkaApis.handleHeartbeatRequest(KafkaApis.scala:1617)
> at kafka.server.KafkaApis.handle(KafkaApis.scala:155) {code}
>
> Looking at the logs, I see a coordinator change just prior to this exception.
> The group was first unloaded as the coordinator moved to another broker and
> then was loaded again as the coordinator was moved back. I am guessing that
> somehow the delayed heartbeat is retaining the reference to the old
> GroupMetadata instance. Not sure exactly how this can happen though.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (KAFKA-8859) Refactor Cache-level Streams Metrics
[ https://issues.apache.org/jira/browse/KAFKA-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bejeck updated KAFKA-8859: --- Affects Version/s: 2.4.0 > Refactor Cache-level Streams Metrics > > > Key: KAFKA-8859 > URL: https://issues.apache.org/jira/browse/KAFKA-8859 > Project: Kafka > Issue Type: Improvement > Components: streams >Affects Versions: 2.4.0 >Reporter: Bruno Cadonna >Assignee: Bruno Cadonna >Priority: Major > > Refactoring of cache-level Streams metrics according KIP-444. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (KAFKA-8859) Refactor Cache-level Streams Metrics
[ https://issues.apache.org/jira/browse/KAFKA-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bejeck updated KAFKA-8859: --- Fix Version/s: 2.4.0 > Refactor Cache-level Streams Metrics > > > Key: KAFKA-8859 > URL: https://issues.apache.org/jira/browse/KAFKA-8859 > Project: Kafka > Issue Type: Improvement > Components: streams >Affects Versions: 2.4.0 >Reporter: Bruno Cadonna >Assignee: Bruno Cadonna >Priority: Major > Fix For: 2.4.0 > > > Refactoring of cache-level Streams metrics according KIP-444. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (KAFKA-8859) Refactor Cache-level Streams Metrics
[ https://issues.apache.org/jira/browse/KAFKA-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bejeck resolved KAFKA-8859. Resolution: Fixed > Refactor Cache-level Streams Metrics > > > Key: KAFKA-8859 > URL: https://issues.apache.org/jira/browse/KAFKA-8859 > Project: Kafka > Issue Type: Improvement > Components: streams >Affects Versions: 2.4.0 >Reporter: Bruno Cadonna >Assignee: Bruno Cadonna >Priority: Major > Fix For: 2.4.0 > > > Refactoring of cache-level Streams metrics according KIP-444. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-8859) Refactor Cache-level Streams Metrics
[ https://issues.apache.org/jira/browse/KAFKA-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935892#comment-16935892 ] ASF GitHub Bot commented on KAFKA-8859: --- bbejeck commented on pull request #7367: KAFKA-8859: Refactor cache-level metrics URL: https://github.com/apache/kafka/pull/7367 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Refactor Cache-level Streams Metrics > > > Key: KAFKA-8859 > URL: https://issues.apache.org/jira/browse/KAFKA-8859 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Bruno Cadonna >Assignee: Bruno Cadonna >Priority: Major > > Refactoring of cache-level Streams metrics according KIP-444. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-7888) kafka cluster not recovering - Shrinking ISR from 14,13 to 13 (kafka.cluster.Partition) continously
[
https://issues.apache.org/jira/browse/KAFKA-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935817#comment-16935817
]
Stoyan Stoyanov commented on KAFKA-7888:
This happened in version 2.2.1 too.
> kafka cluster not recovering - Shrinking ISR from 14,13 to 13
> (kafka.cluster.Partition) continously
> ---
>
> Key: KAFKA-7888
> URL: https://issues.apache.org/jira/browse/KAFKA-7888
> Project: Kafka
> Issue Type: Bug
> Components: controller, replication, zkclient
>Affects Versions: 2.1.0
> Environment: using kafka_2.12-2.1.0
> 3 ZKs 3 Broker cluster, using 3 boxes (1 ZK and 1 broker on each box),
> default.replication factor: 2,
> offset replication factor was 1 when the error happened, increased to 2 after
> seeing this error by reassigning-partitions.
> compression: default (producer) on broker but sending gzip from producers.
> linux (redhat) etx4 kafka logs on single local disk
>Reporter: Kemal ERDEN
>Priority: Major
> Attachments: combined.log, producer.log
>
>
> we're seeing the following repeating logs on our kafka cluster from time to
> time which seems to cause messages expiring on Producers and the cluster
> going into a non-recoverable state. The only fix seems to be to restart
> brokers.
> {{Shrinking ISR from 14,13 to 13 (kafka.cluster.Partition)}}
> {{Cached zkVersion [21] not equal to that in zookeeper, skip updating ISR
> (kafka.cluster.Partition)}}
> and later on the following log is repeated:
> {{Got user-level KeeperException when processing sessionid:0xe046aa4f8e6
> type:setData cxid:0x2df zxid:0xa01fd txntype:-1 reqpath:n/a Error
> Path:/brokers/topics/ucTrade/partitions/6/state Error:KeeperErrorCode =
> BadVersion for /brokers/topics/ucTrade/partitions/6/state}}
> We haven't interfered with any of the brokers/zookeepers whilst this happened.
> I've attached a combined log which represents a combination of controller,
> server and state change logs from each broker (ids 13,14 and 15, log files
> have the suffix b13, b14, b15 respectively)
> We have increased the heaps from 1g to 6g for the brokers and from 512m to 4g
> for the zookeepers since this happened but not sure if it is relevant. the ZK
> logs are unfortunately overwritten so can't provide those.
> We produce varying message sizes but some messages are relatively large (6mb)
> but we use compression on the producers (set to gzip).
> I've attached some logs from one of our producers as well.
> producer.properties that we've changed:
> spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
> spring.kafka.producer.compression-type=gzip
> spring.kafka.producer.retries=5
> spring.kafka.producer.acks=-1
> spring.kafka.producer.batch-size=1048576
> spring.kafka.producer.properties.linger.ms=200
> spring.kafka.producer.properties.request.timeout.ms=60
> spring.kafka.producer.properties.max.block.ms=24
> spring.kafka.producer.properties.max.request.size=104857600
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KAFKA-7625) Kafka Broker node JVM crash - kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction
[
https://issues.apache.org/jira/browse/KAFKA-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935783#comment-16935783
]
fenghong edited comment on KAFKA-7625 at 9/23/19 12:08 PM:
---
There are 2 solutions:
*1. Upgrade the JDK to version 1.8.0_192 or later.*
*2. Adjust the garbage collection strategy from G1 to CMS.*
was (Author: fenghong):
There are 2 solutions:
*1. Upgrade the JDK to version 1.8.0_192 or later.*
*2. Adjust the garbage collection strategy from G1 to CMS.*
> Kafka Broker node JVM crash -
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction
>
>
> Key: KAFKA-7625
> URL: https://issues.apache.org/jira/browse/KAFKA-7625
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.0
> Environment: environment:os.version=2.6.32-754.2.1.el6.x86_64
> java.version=1.8.0_92
> environment:zookeeper.version=3.4.13-2d71af4dbe22557fda74f9a9b4309b15a7487f03,
> built on 06/29/2018 00:39 GMT (org.apache.zookeeper.ZooKeeper)
> Kafka commitId : 3402a8361b734732
>Reporter: Sebastian Puzoń
>Priority: Critical
> Attachments: hs_err_pid10238.log, hs_err_pid15119.log,
> hs_err_pid19131.log, hs_err_pid19405.log, hs_err_pid20124.log,
> hs_err_pid22373.log, hs_err_pid22386.log, hs_err_pid22633.log,
> hs_err_pid24681.log, hs_err_pid25513.log, hs_err_pid25701.log,
> hs_err_pid26844.log, hs_err_pid27156.log, hs_err_pid27290.log,
> hs_err_pid4194.log, hs_err_pid4299.log
>
>
> I observe broker node JVM crashes with same problematic frame:
> {code:java}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7ff4a2588261, pid=24681, tid=0x7ff3b9bb1700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build
> 1.8.0_92-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # J 9736 C1
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction$7(Lkafka/coordinator/transaction/TransactionCoordinator;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;Lkafka/coordinator/transaction/TransactionMetadata;)Lscala/util/Either;
> (518 bytes) @ 0x7ff4a2588261 [0x7ff4a25871a0+0x10c1]
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
> --- T H R E A D ---
> Current thread (0x7ff4b356f800): JavaThread "kafka-request-handler-3"
> daemon [_thread_in_Java, id=24781,
> stack(0x7ff3b9ab1000,0x7ff3b9bb2000)]
> {code}
> {code:java}
> Stack: [0x7ff3b9ab1000,0x7ff3b9bb2000], sp=0x7ff3b9bafca0, free
> space=1019k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> J 9736 C1
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction$7(Lkafka/coordinator/transaction/TransactionCoordinator;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;Lkafka/coordinator/transaction/TransactionMetadata;)Lscala/util/Either;
> (518 bytes) @ 0x7ff4a2588261 [0x7ff4a25871a0+0x10c1]
> J 10456 C2
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction$5(Lkafka/coordinator/transaction/TransactionCoordinator;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;ILscala/Option;)Lscala/util/Either;
> (192 bytes) @ 0x7ff4a1d413f0 [0x7ff4a1d41240+0x1b0]
> J 9303 C1
> kafka.coordinator.transaction.TransactionCoordinator$$Lambda$1107.apply(Ljava/lang/Object;)Ljava/lang/Object;
> (32 bytes) @ 0x7ff4a245f55c [0x7ff4a245f3c0+0x19c]
> J 10018 C2
> scala.util.Either$RightProjection.flatMap(Lscala/Function1;)Lscala/util/Either;
> (43 bytes) @ 0x7ff4a1f242c4 [0x7ff4a1f24260+0x64]
> J 9644 C1
> kafka.coordinator.transaction.TransactionCoordinator.sendTxnMarkersCallback$1(Lorg/apache/kafka/common/protocol/Errors;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;Lscala/Function1;ILkafka/coordinator/transaction/TxnTransitMetadata;)V
> (251 bytes) @ 0x7ff4a1ef6254 [0x7ff4a1ef5120+0x1134]
> J 9302 C1
> kafka.coordinator.transaction.TransactionCoordinator$$Lambda$1106.apply(Ljava/lang/Object;)Ljava/lang/Object;
> (40 bytes) @ 0x7ff4a24747ec [0x7ff4a24745a0+0x24c]
> J 10125 C2
>
[jira] [Commented] (KAFKA-7625) Kafka Broker node JVM crash - kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction
[
https://issues.apache.org/jira/browse/KAFKA-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935783#comment-16935783
]
fenghong commented on KAFKA-7625:
-
There are 2 solutions:
*1. Upgrade the JDK to version 1.8.0_192 or later.*
*2. Adjust the garbage collection strategy from G1 to CMS.*
> Kafka Broker node JVM crash -
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction
>
>
> Key: KAFKA-7625
> URL: https://issues.apache.org/jira/browse/KAFKA-7625
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.0
> Environment: environment:os.version=2.6.32-754.2.1.el6.x86_64
> java.version=1.8.0_92
> environment:zookeeper.version=3.4.13-2d71af4dbe22557fda74f9a9b4309b15a7487f03,
> built on 06/29/2018 00:39 GMT (org.apache.zookeeper.ZooKeeper)
> Kafka commitId : 3402a8361b734732
>Reporter: Sebastian Puzoń
>Priority: Critical
> Attachments: hs_err_pid10238.log, hs_err_pid15119.log,
> hs_err_pid19131.log, hs_err_pid19405.log, hs_err_pid20124.log,
> hs_err_pid22373.log, hs_err_pid22386.log, hs_err_pid22633.log,
> hs_err_pid24681.log, hs_err_pid25513.log, hs_err_pid25701.log,
> hs_err_pid26844.log, hs_err_pid27156.log, hs_err_pid27290.log,
> hs_err_pid4194.log, hs_err_pid4299.log
>
>
> I observe broker node JVM crashes with same problematic frame:
> {code:java}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7ff4a2588261, pid=24681, tid=0x7ff3b9bb1700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build
> 1.8.0_92-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # J 9736 C1
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction$7(Lkafka/coordinator/transaction/TransactionCoordinator;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;Lkafka/coordinator/transaction/TransactionMetadata;)Lscala/util/Either;
> (518 bytes) @ 0x7ff4a2588261 [0x7ff4a25871a0+0x10c1]
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
> --- T H R E A D ---
> Current thread (0x7ff4b356f800): JavaThread "kafka-request-handler-3"
> daemon [_thread_in_Java, id=24781,
> stack(0x7ff3b9ab1000,0x7ff3b9bb2000)]
> {code}
> {code:java}
> Stack: [0x7ff3b9ab1000,0x7ff3b9bb2000], sp=0x7ff3b9bafca0, free
> space=1019k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> J 9736 C1
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction$7(Lkafka/coordinator/transaction/TransactionCoordinator;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;Lkafka/coordinator/transaction/TransactionMetadata;)Lscala/util/Either;
> (518 bytes) @ 0x7ff4a2588261 [0x7ff4a25871a0+0x10c1]
> J 10456 C2
> kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleEndTransaction$5(Lkafka/coordinator/transaction/TransactionCoordinator;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;ILscala/Option;)Lscala/util/Either;
> (192 bytes) @ 0x7ff4a1d413f0 [0x7ff4a1d41240+0x1b0]
> J 9303 C1
> kafka.coordinator.transaction.TransactionCoordinator$$Lambda$1107.apply(Ljava/lang/Object;)Ljava/lang/Object;
> (32 bytes) @ 0x7ff4a245f55c [0x7ff4a245f3c0+0x19c]
> J 10018 C2
> scala.util.Either$RightProjection.flatMap(Lscala/Function1;)Lscala/util/Either;
> (43 bytes) @ 0x7ff4a1f242c4 [0x7ff4a1f24260+0x64]
> J 9644 C1
> kafka.coordinator.transaction.TransactionCoordinator.sendTxnMarkersCallback$1(Lorg/apache/kafka/common/protocol/Errors;Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResult;Lscala/Function1;ILkafka/coordinator/transaction/TxnTransitMetadata;)V
> (251 bytes) @ 0x7ff4a1ef6254 [0x7ff4a1ef5120+0x1134]
> J 9302 C1
> kafka.coordinator.transaction.TransactionCoordinator$$Lambda$1106.apply(Ljava/lang/Object;)Ljava/lang/Object;
> (40 bytes) @ 0x7ff4a24747ec [0x7ff4a24745a0+0x24c]
> J 10125 C2
> kafka.coordinator.transaction.TransactionStateManager.updateCacheCallback$1(Lscala/collection/Map;Ljava/lang/String;ILkafka/coordinator/transaction/TxnTransitMetadata;Lscala/Function1;Lscala/Function1;Lorg/apache/kafka/common/TopicPartition;)V
> (892 bytes) @ 0x7ff4a27045ec [0x7ff4a2703c60+0x98c]
> J 10051 C2
>
[jira] [Commented] (KAFKA-8834) Distinguish URPs caused by reassignment plus other metrics
[ https://issues.apache.org/jira/browse/KAFKA-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935698#comment-16935698 ] Viktor Somogyi-Vass commented on KAFKA-8834: I'll add both then. > Distinguish URPs caused by reassignment plus other metrics > -- > > Key: KAFKA-8834 > URL: https://issues.apache.org/jira/browse/KAFKA-8834 > Project: Kafka > Issue Type: Improvement >Reporter: Jason Gustafson >Assignee: Viktor Somogyi-Vass >Priority: Major > > This Jira tracks implementation of KIP-352: > [https://cwiki.apache.org/confluence/display/KAFKA/KIP-352%3A+Distinguish+URPs+caused+by+reassignment]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-8327) Connection to Node2 was disconnected
[
https://issues.apache.org/jira/browse/KAFKA-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935604#comment-16935604
]
Mohit Kumar commented on KAFKA-8327:
This has been solved by increasing the value of
{{replica.socket.receive.buffer.bytes}} in all destination brokers.
After changing the above parameter and restarting broker. I was able to see the
data in above-mentioned partitions.
> Connection to Node2 was disconnected
> -
>
> Key: KAFKA-8327
> URL: https://issues.apache.org/jira/browse/KAFKA-8327
> Project: Kafka
> Issue Type: New Feature
> Components: consumer
>Affects Versions: 1.1.0
>Reporter: suseendramani
>Priority: Major
>
> Hi Team,
>
> we are seeing the below errors in the kafka logs. We are using the kafka
> version 1.1.0, COuld you please let us know if there are any fixes that can
> be applied to this ?
>
> [2019-05-06 20:40:23,212] INFO [ReplicaFetcher replicaId=3, leaderId=2,
> fetcherId=0] Error sending fetch request (sessionId=896515694, epoch=738904)
> to node 2: java.io.IOException: Connection to 2 was disconnected before the
> response wa
> s read. (org.apache.kafka.clients.FetchSessionHandler)
> [2019-05-06 20:40:23,422] WARN [ReplicaFetcher replicaId=3, leaderId=2,
> fetcherId=0] Error in response for fetch request (type=FetchRequest,
> replicaId=3, maxWait=500, minBytes=1, maxBytes=10485760,
> fetchData=\{xxx-12=(offset=38826573, logStartOffset=38549032,
> maxBytes=1048576), xx-14=(offset=49033, logStartOffset=0,
> maxBytes=1048576), rWithSubscription-Cas-3=(offset=40752457,
> logStartOffset=40198369, maxBytes=1048576), xx-8=(offset=39543295,
> logStartOffset=39032103, maxBytes=1048576)}, isolationLevel=READ_UNCOMMITTED,
> toForget=, metadata=(s
> essionId=896515694, epoch=738904)) (kafka.server.ReplicaFetcherThread)
> java.io.IOException: Connection to 2 was disconnected before the response was
> read
>
> We are also seeing the below errors..
>
> [2019-05-07 01:39:57,310] INFO [ReplicaFetcher replicaId=0, leaderId=4,
> fetcherId=0] Retrying leaderEpoch request for partition __consumer_offsets-31
> as the leader reported an error: NOT_LEADER_FOR_PARTITION
> (kafka.server.ReplicaFetcherThread)
>
> Please let us know the reason for the same.
>
> Thanks,
> Mani
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
