[jira] [Commented] (KAFKA-14442) GlobalKTable restoration waits requestTimeout during application restart
[ https://issues.apache.org/jira/browse/KAFKA-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691033#comment-17691033 ] Gergo L��p commented on KAFKA-14442: Ahh, thanks! I tried with the 3.2.0 version and it works like a charm. Thank you! > GlobalKTable restoration waits requestTimeout during application restart > > > Key: KAFKA-14442 > URL: https://issues.apache.org/jira/browse/KAFKA-14442 > Project: Kafka > Issue Type: Bug > Components: streams >Affects Versions: 3.0.0 >Reporter: Gergo L��p >Priority: Major > > Using "exactly_once_beta" the highWatermark "skips" an offset after a > transaction but in this case the global .checkpoint file contains different > value (smaller by 1) than the highWatermark. > During restoration because of the difference between the checkpoint and > highWatermark a poll will be attempted but sometimes there is no new record > on the partition and the GlobalStreamThread has to wait for the > requestTimeout to continue. > If there is any new record on the partition the problem does not occure. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KAFKA-14442) GlobalKTable restoration waits requestTimeout during application restart
[ https://issues.apache.org/jira/browse/KAFKA-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690563#comment-17690563 ] Matthias J. Sax commented on KAFKA-14442: - Just learned about https://issues.apache.org/jira/browse/KAFKA-12980 – we should verify it it would actually fix this issue, similar to https://issues.apache.org/jira/browse/KAFKA-14713 > GlobalKTable restoration waits requestTimeout during application restart > > > Key: KAFKA-14442 > URL: https://issues.apache.org/jira/browse/KAFKA-14442 > Project: Kafka > Issue Type: Bug > Components: streams >Affects Versions: 3.0.0 >Reporter: Gergo L��p >Priority: Major > > Using "exactly_once_beta" the highWatermark "skips" an offset after a > transaction but in this case the global .checkpoint file contains different > value (smaller by 1) than the highWatermark. > During restoration because of the difference between the checkpoint and > highWatermark a poll will be attempted but sometimes there is no new record > on the partition and the GlobalStreamThread has to wait for the > requestTimeout to continue. > If there is any new record on the partition the problem does not occure. -- This message was sent by Atlassian Jira (v8.20.10#820010)
