[jira] [Commented] (KAFKA-6782) GlobalStateStore never finishes restoring when consuming transactional messages
[
https://issues.apache.org/jira/browse/KAFKA-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437018#comment-16437018
]
Lingxiao WANG commented on KAFKA-6782:
--
Yes, I think GlobalKTables will have the same problem. I'm trying to add PR and
test for it.
> GlobalStateStore never finishes restoring when consuming transactional
> messages
> ---
>
> Key: KAFKA-6782
> URL: https://issues.apache.org/jira/browse/KAFKA-6782
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 1.1.0, 1.0.1
>Reporter: Lingxiao WANG
>Priority: Major
>
> Same problem with https://issues.apache.org/jira/browse/KAFKA-6190, but his
> proposition :
> {code:java}
> while (offset < highWatermark) {
> final ConsumerRecords records = consumer.poll(100);
> for (ConsumerRecord record : records) {
> if (record.key() != null) {
>stateRestoreCallback.restore(record.key(), record.value());
> }
> offset = consumer.position(topicPartition);
> }
> }{code}
> doesn't work for me. In my situation, there is chance to have several
> transaction markers appear in sequence in one partition. In this case, the
> consumer is blocked and can't poll any records, and the code 'offset =
> consumer.position(topicPartition)' doesn't have any opportunity to execute.
> So I propose to move the code 'offset = consumer.position(topicPartition)'
> outside of the cycle to guarantee that event if no records are polled, the
> offset can always be updated.
> {code:java}
> while (offset < highWatermark) {
> final ConsumerRecords records = consumer.poll(100);
> for (ConsumerRecord record : records) {
> if (record.key() != null) {
>stateRestoreCallback.restore(record.key(), record.value());
> }
> }
> offset = consumer.position(topicPartition);
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (KAFKA-6772) Broker should load credentials from ZK before requests are allowed
[ https://issues.apache.org/jira/browse/KAFKA-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram reassigned KAFKA-6772: - Assignee: Rajini Sivaram > Broker should load credentials from ZK before requests are allowed > -- > > Key: KAFKA-6772 > URL: https://issues.apache.org/jira/browse/KAFKA-6772 > Project: Kafka > Issue Type: Improvement >Affects Versions: 1.0.0, 1.1.0, 1.0.1 >Reporter: Ismael Juma >Assignee: Rajini Sivaram >Priority: Major > Fix For: 1.0.2, 1.2.0, 1.1.1 > > > It is currently possible for clients to get an AuthenticationException during > start-up if the brokers have not yet loaded credentials from ZK. This > definitely affects SCRAM, but it may also affect delegation tokens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6778) DescribeConfigs does not return error for non-existent topic
[
https://issues.apache.org/jira/browse/KAFKA-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437073#comment-16437073
]
ASF GitHub Bot commented on KAFKA-6778:
---
omkreddy opened a new pull request #4866: KAFKA-6778:
AdminClient.describeConfigs() should return error for non-existent topics
URL: https://github.com/apache/kafka/pull/4866
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> DescribeConfigs does not return error for non-existent topic
>
>
> Key: KAFKA-6778
> URL: https://issues.apache.org/jira/browse/KAFKA-6778
> Project: Kafka
> Issue Type: Bug
> Components: admin
>Affects Versions: 1.1.0
>Reporter: Magnus Edenhill
>Assignee: Manikumar
>Priority: Major
>
> Sending a DescribeConfigsRequest with a ConfigResource(TOPIC,
> "non-existent-topic") returns a fully populated ConfigResource back in the
> response with 24 configuration entries.
> A resource-level error_code of UnknownTopic.. would be expected instead.
>
> {code:java}
> [0081_admin / 1.143s] ConfigResource #0: type TOPIC (2),
> "rdkafkatest_rnd3df408bf5d94d696_DescribeConfigs_notexist": 24 ConfigEntries,
> error NO_ERROR ()
> [0081_admin / 1.144s] #0/24: Source UNKNOWN (5):
> "compression.type"="producer" [is read-only=n, default=n, sensitive=n,
> synonym=n] with 1 synonym(s)
>
> {code}
> But the topic does not exist:
> {code:java}
> $ $KAFKA_PATH/bin/kafka-topics.sh --zookeeper $ZK_ADDRESS --list | grep
> rdkafkatest_rnd3df408bf5d94d696_DescribeConfigs_notexist ; echo $?
> 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KAFKA-6772) Broker should load credentials from ZK before requests are allowed
[ https://issues.apache.org/jira/browse/KAFKA-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437176#comment-16437176 ] ASF GitHub Bot commented on KAFKA-6772: --- rajinisivaram opened a new pull request #4867: KAFKA-6772: Load credentials from ZK before accepting connections URL: https://github.com/apache/kafka/pull/4867 Reorder startup sequence in `KafkaServer` to ensure that credentials are loaded from ZK into cache before socket connections are accepted. ### 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 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 > Broker should load credentials from ZK before requests are allowed > -- > > Key: KAFKA-6772 > URL: https://issues.apache.org/jira/browse/KAFKA-6772 > Project: Kafka > Issue Type: Improvement >Affects Versions: 1.0.0, 1.1.0, 1.0.1 >Reporter: Ismael Juma >Assignee: Rajini Sivaram >Priority: Major > Fix For: 1.0.2, 1.2.0, 1.1.1 > > > It is currently possible for clients to get an AuthenticationException during > start-up if the brokers have not yet loaded credentials from ZK. This > definitely affects SCRAM, but it may also affect delegation tokens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6777) Wrong reaction on Out Of Memory situation
[ https://issues.apache.org/jira/browse/KAFKA-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437181#comment-16437181 ] Seweryn Habdank-Wojewodzki commented on KAFKA-6777: --- Our options: -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true > Wrong reaction on Out Of Memory situation > - > > Key: KAFKA-6777 > URL: https://issues.apache.org/jira/browse/KAFKA-6777 > Project: Kafka > Issue Type: Bug > Components: core >Affects Versions: 1.0.0 >Reporter: Seweryn Habdank-Wojewodzki >Priority: Critical > Attachments: screenshot-1.png > > > Dears, > We already encountered many times problems related to Out Of Memory situation > in Kafka Broker and streaming clients. > The scenario is the following. > When Kafka Broker (or Streaming Client) is under load and has too less > memory, there are no errors in server logs. One can see some cryptic entries > in GC logs, but they are definitely not self-explaining. > Kafka Broker (and Streaming Clients) works further. Later we see in JMX > monitoring, that JVM uses more and more time in GC. In our case it grows from > e.g. 1% to 80%-90% of CPU time is used by GC. > Next, software collapses into zombie mode – process in not ending. In such a > case I would expect, that process is crashing (e.g. got SIG SEGV). Even worse > Kafka treats such a zombie process normal and somewhat sends messages, which > are in fact getting lost, also the cluster is not excluding broken nodes. The > question is how to configure Kafka to really terminate the JVM and not remain > in zombie mode, to give a chance to other nodes to know, that something is > dead. > I would expect that in Out Of Memory situation JVM is ended if not graceful > than at least process is crashed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (KAFKA-6677) Remove EOS producer config max.in.flight.request.per.connection=1
[ https://issues.apache.org/jira/browse/KAFKA-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jagadesh Adireddi reassigned KAFKA-6677: Assignee: Jagadesh Adireddi > Remove EOS producer config max.in.flight.request.per.connection=1 > - > > Key: KAFKA-6677 > URL: https://issues.apache.org/jira/browse/KAFKA-6677 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Matthias J. Sax >Assignee: Jagadesh Adireddi >Priority: Major > > When EOS was introduced in 0.11, it was required to set producer config > max.in.flight.requests.per.connection=1 for idempotent producer. > This limitations as fixed in 1.0 release via KAFKA-5494 > Thus, we should remove this setting in Kafka Streams if EOS get's enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6677) Remove EOS producer config max.in.flight.request.per.connection=1
[ https://issues.apache.org/jira/browse/KAFKA-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437274#comment-16437274 ] ASF GitHub Bot commented on KAFKA-6677: --- jadireddi opened a new pull request #4868: KAFKA-6677: Fixed streamconfig producer's maxinflight allowed when EOS Enabled. URL: https://github.com/apache/kafka/pull/4868 https://issues.apache.org/jira/browse/KAFKA-6677 Modified `StreamsConfig` Producer's default MaxInFlight Request allowed per connection. *More detailed description of your change, if necessary. The PR title and PR message become the squashed commit message, so use a separate comment to ping reviewers.* *Summary of testing strategy (including rationale) for the feature or bug fix. Unit and/or integration tests are expected for any behaviour change and system tests should be considered for larger changes.* ### 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 GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove EOS producer config max.in.flight.request.per.connection=1 > - > > Key: KAFKA-6677 > URL: https://issues.apache.org/jira/browse/KAFKA-6677 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Matthias J. Sax >Assignee: Jagadesh Adireddi >Priority: Major > > When EOS was introduced in 0.11, it was required to set producer config > max.in.flight.requests.per.connection=1 for idempotent producer. > This limitations as fixed in 1.0 release via KAFKA-5494 > Thus, we should remove this setting in Kafka Streams if EOS get's enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6765) Intermittent test failure in CustomQuotaCallbackTest
[
https://issues.apache.org/jira/browse/KAFKA-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437286#comment-16437286
]
ASF GitHub Bot commented on KAFKA-6765:
---
rajinisivaram opened a new pull request #4869: KAFKA-6765: Handle exception
while reading throttle metric value in test
URL: https://github.com/apache/kafka/pull/4869
CustomQuotaCallback tests wait for throttle metric to be updated without
waiting for requests to complete to avoid waiting for potentially large
throttle times. This requires the test to read metric values while a broker may
be updating the value, resulting in exception in the test. Add retry in the
test to handle this case.
### 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 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
> Intermittent test failure in CustomQuotaCallbackTest
>
>
> Key: KAFKA-6765
> URL: https://issues.apache.org/jira/browse/KAFKA-6765
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.0
>Reporter: Rajini Sivaram
>Assignee: Rajini Sivaram
>Priority: Major
> Fix For: 1.2.0
>
>
> Exception stack trace:
> {quote}
> java.lang.NullPointerException at
> org.apache.kafka.common.metrics.stats.SampledStat.purgeObsoleteSamples(SampledStat.java:104)
> at
> org.apache.kafka.common.metrics.stats.SampledStat.measure(SampledStat.java:74)
> at
> org.apache.kafka.common.metrics.KafkaMetric.metricValue(KafkaMetric.java:68)
> at kafka.api.QuotaTestClients$.metricValue(BaseQuotaTest.scala:163) at
> kafka.api.QuotaTestClients.produceUntilThrottled(BaseQuotaTest.scala:193) at
> kafka.api.CustomQuotaCallbackTest$GroupedUser.produceConsume(CustomQuotaCallbackTest.scala:272)
> at
> kafka.api.CustomQuotaCallbackTest.testCustomQuotaCallback(CustomQuotaCallbackTest.scala:146)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KAFKA-6677) Remove EOS producer config max.in.flight.request.per.connection=1
[ https://issues.apache.org/jira/browse/KAFKA-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437360#comment-16437360 ] Jagadesh Adireddi commented on KAFKA-6677: -- Hi @mjsax , Fixed `StreamsConfig` to set the default to 5, and allow users to configure a smaller value if they wish, and throw an exception if they configure a larger value. Can you please review and let me know if any changes needed. > Remove EOS producer config max.in.flight.request.per.connection=1 > - > > Key: KAFKA-6677 > URL: https://issues.apache.org/jira/browse/KAFKA-6677 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: Matthias J. Sax >Assignee: Jagadesh Adireddi >Priority: Major > > When EOS was introduced in 0.11, it was required to set producer config > max.in.flight.requests.per.connection=1 for idempotent producer. > This limitations as fixed in 1.0 release via KAFKA-5494 > Thus, we should remove this setting in Kafka Streams if EOS get's enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KAFKA-2661) Add a unit test for disconnecting idle socket connections
[ https://issues.apache.org/jira/browse/KAFKA-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar resolved KAFKA-2661. -- Resolution: Fixed SelectorTest.testCloseConnectionInClosingState/testCloseOldestConnection tests covers unit test case for idle connections. > Add a unit test for disconnecting idle socket connections > -- > > Key: KAFKA-2661 > URL: https://issues.apache.org/jira/browse/KAFKA-2661 > Project: Kafka > Issue Type: Test > Components: core >Reporter: Jun Rao >Priority: Major > > The logic for disconnecting idle connections is now moved to Selector. We > just need to add a unit test to verify that it works. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-6376) Improve Streams metrics for skipped records
[
https://issues.apache.org/jira/browse/KAFKA-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437879#comment-16437879
]
ASF GitHub Bot commented on KAFKA-6376:
---
vvcephei opened a new pull request #4872: KAFKA-6376: preliminary cleanup
before main PR
URL: https://github.com/apache/kafka/pull/4872
I'm extracting all the (requested and voluntary) code cleanup
from the main PR for KAFKA-6376, since it wound up being a lot of
trivial changes.
The regular testing suite should be sufficient.
### 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 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
> Improve Streams metrics for skipped records
> ---
>
> Key: KAFKA-6376
> URL: https://issues.apache.org/jira/browse/KAFKA-6376
> Project: Kafka
> Issue Type: Improvement
> Components: metrics, streams
>Affects Versions: 1.0.0
>Reporter: Matthias J. Sax
>Assignee: John Roesler
>Priority: Major
> Labels: kip
>
> Copy this from KIP-210 discussion thread:
> {quote}
> Note that currently we have two metrics for `skipped-records` on different
> levels:
> 1) on the highest level, the thread-level, we have a `skipped-records`,
> that records all the skipped records due to deserialization errors.
> 2) on the lower processor-node level, we have a
> `skippedDueToDeserializationError`, that records the skipped records on
> that specific source node due to deserialization errors.
> So you can see that 1) does not cover any other scenarios and can just be
> thought of as an aggregate of 2) across all the tasks' source nodes.
> However, there are other places that can cause a record to be dropped, for
> example:
> 1) https://issues.apache.org/jira/browse/KAFKA-5784: records could be
> dropped due to window elapsed.
> 2) KIP-210: records could be dropped on the producer side.
> 3) records could be dropped during user-customized processing on errors.
> {quote}
> [~guozhang] Not sure what you mean by "3) records could be dropped during
> user-customized processing on errors."
> Btw: we also drop record with {{null}} key and/or value for certain DSL
> operations. This should be included as well.
> KIP: :
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-274%3A+Kafka+Streams+Skipped+Records+Metrics
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
