[GitHub] [kafka] chia7712 commented on pull request #9223: KAFKA-10438 Lazy initialization of record header to reduce memory usa…
chia7712 commented on pull request #9223: URL: https://github.com/apache/kafka/pull/9223#issuecomment-691835512 ``` Build / JDK 8 / org.apache.kafka.connect.mirror.MirrorConnectorsIntegrationTest.testReplication 1 分 17 秒1 Build / JDK 15 / kafka.api.SaslSslAdminIntegrationTest.testCreateDeleteTopics 2 分 2 秒 1 Build / JDK 15 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true] 1 分 21 秒1 Build / JDK 15 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true] ``` I don't observe the relation between those failures and this patch. 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
[GitHub] [kafka] chia7712 commented on pull request #8978: KAFKA-10234 The key/value deserializer used by ConsoleConsumer is not…
chia7712 commented on pull request #8978: URL: https://github.com/apache/kafka/pull/8978#issuecomment-691790414 ``` Build / JDK 8 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true] Build / JDK 15 / kafka.network.DynamicConnectionQuotaTest.testDynamicListenerConnectionCreationRateQuota Build / JDK 15 / kafka.network.DynamicConnectionQuotaTest.testDynamicListenerConnectionCreationRateQuota Build / JDK 15 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true] ``` unrelated failure 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
[jira] [Updated] (KAFKA-10461) The config of closing heartbeat is invalid.
[ https://issues.apache.org/jira/browse/KAFKA-10461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jiwei updated KAFKA-10461: -- Affects Version/s: (was: 2.6.0) 2.4.1 > The config of closing heartbeat is invalid. > --- > > Key: KAFKA-10461 > URL: https://issues.apache.org/jira/browse/KAFKA-10461 > Project: Kafka > Issue Type: Improvement > Components: KafkaConnect >Affects Versions: 2.4.1 >Reporter: jiwei >Assignee: jiwei >Priority: Critical > Attachments: image-2020-09-04-11-29-58-624.png > > > public static final String EMIT_HEARTBEATS_ENABLED = EMIT_HEARTBEATS + > ENABLED_SUFFIX; > private static final String EMIT_HEARTBEATS_ENABLED_DOC = "Whether to emit > heartbeats to target cluster."; > When I set it "false", it dosen‘t work! > !image-2020-09-04-11-29-58-624.png|width=448,height=260! > While the value of interval is "-1", method stopped.await(-1) will return > false. Then MirrorHeartbeatTask will emit heartbeat one by one endlessly. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [kafka] jiweiautohome closed pull request #9250: KAFKA-10461 The config of closing heartbeat is invalid.
jiweiautohome closed pull request #9250: URL: https://github.com/apache/kafka/pull/9250 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
[GitHub] [kafka] jiweiautohome commented on pull request #9250: KAFKA-10461 The config of closing heartbeat is invalid.
jiweiautohome commented on pull request #9250: URL: https://github.com/apache/kafka/pull/9250#issuecomment-691780660 The version of kafka we using is 2.4. It's fixed in 2.5. https://github.com/apache/kafka/blob/5fa66b3b8c43c4e7de591704581de88fd911a705/connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorHeartbeatConnector.java#L54 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
[GitHub] [kafka] jiweiautohome removed a comment on pull request #9250: KAFKA-10461 The config of closing heartbeat is invalid.
jiweiautohome removed a comment on pull request #9250: URL: https://github.com/apache/kafka/pull/9250#issuecomment-691780087 > Could you add unit test? The version of kafka we using is 2.4. It's fixed in 2.5. https://github.com/apache/kafka/blob/16ec1793d53700623c9cb43e711f585aafd44dd4/connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorHeartbeatConnector.java#L64 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
[GitHub] [kafka] jiweiautohome commented on pull request #9250: KAFKA-10461 The config of closing heartbeat is invalid.
jiweiautohome commented on pull request #9250: URL: https://github.com/apache/kafka/pull/9250#issuecomment-691780087 > Could you add unit test? The version of kafka we using is 2.4. It's fixed in 2.5. https://github.com/apache/kafka/blob/16ec1793d53700623c9cb43e711f585aafd44dd4/connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorHeartbeatConnector.java#L64 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
[jira] [Commented] (KAFKA-6221) ReplicaFetcherThread throws UnknownTopicOrPartitionException on topic creation
[
https://issues.apache.org/jira/browse/KAFKA-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195157#comment-17195157
]
nandini commented on KAFKA-6221:
https://issues.apache.org/jira/browse/KAFKA-8264
https://issues.apache.org/jira/browse/KAFKA-7965
https://issues.apache.org/jira/browse/KAFKA-8087
https://issues.apache.org/jira/browse/KAFKA-9181
https://issues.apache.org/jira/browse/KAFKA-7976
And many other related jiras. Do they address the same?
> ReplicaFetcherThread throws UnknownTopicOrPartitionException on topic
> creation
> ---
>
> Key: KAFKA-6221
> URL: https://issues.apache.org/jira/browse/KAFKA-6221
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 0.10.1.1, 0.10.2.0, 0.10.2.1, 0.11.0.1, 1.0.0
> Environment: RHEL 7
>Reporter: Alex Dunayevsky
>Priority: Minor
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> This issue appeared to happen frequently on 0.10.2.0.
> On 0.10.2.1 and 1.0.0 it's a way harder to reproduce.
> We'll focus on reproducing it on 0.10.2.1 and 1.0.0.
> *TOPOLOGY:*
> 3 brokers, 1 zk.
> *REPRODUCING STRATEGY:*
> Create a few dozens topics (say, 40) one by one, each with replication factor
> 2. Number of partitions, generally, does not matter but, for easier
> reproduction, should not be too small (around 30 or so).
> *CREATE 40 TOPICS:*
> {code:java} for i in {1..40}; do bin/kafka-topics.sh --create --topic
> "topic${i}_p28_r2" --partitions 28 --replication-factor 2 --zookeeper :2165;
> done {code}
> *ERRORS*
> {code:java}
> *BROKER 1*
> [2017-11-15 16:46:00,853] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,27] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,853] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,27] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,9] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,9] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,3] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,3] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,15] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,15] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,21] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:00,854] ERROR [ReplicaFetcherThread-0-2], Error for
> partition [topic1_p28_r2,21] to broker
> 2:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> *BROKER 2*
> [2017-11-15 16:46:36,408] ERROR [ReplicaFetcherThread-0-3], Error for
> partition [topic20_p28_r2,12] to broker
> 3:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server does not host this topic-partition. (kafka.server.ReplicaFetcherThread)
> [2017-11-15 16:46:36,408] ERROR [ReplicaFetcherThread-0-3], Error for
> partition [topic20_p28_r2,12] to broker
> 3:org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This
> server
[GitHub] [kafka] apovzner commented on a change in pull request #9272: KAFKA-10458; Updating controller quota does not work since Token Bucket
apovzner commented on a change in pull request #9272:
URL: https://github.com/apache/kafka/pull/9272#discussion_r487593129
##
File path: clients/src/main/java/org/apache/kafka/common/metrics/Sensor.java
##
@@ -53,12 +54,20 @@
private final Object metricLock;
private static class StatAndConfig {
-public final Stat stat;
-public final MetricConfig config;
+private final Stat stat;
+private final Supplier configSupplier;
-StatAndConfig(Stat stat, MetricConfig config) {
+StatAndConfig(Stat stat, Supplier configSupplier) {
this.stat = stat;
-this.config = config;
+this.configSupplier = configSupplier;
+}
+
+public Stat stat() {
+return this.stat;
Review comment:
nit: `this` is not really needed, since it's not ambiguous here as in
constructor,
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
[jira] [Comment Edited] (KAFKA-10475) Using same key reports different count of records for groupBy() and groupByKey() in Kafka Streaming Application
[
https://issues.apache.org/jira/browse/KAFKA-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195112#comment-17195112
]
Divya Guduru edited comment on KAFKA-10475 at 9/13/20, 8:06 PM:
I would like to work on this issue.. [~mjsax]
was (Author: divya guduru):
I would like to work on this issue.. can someone update my name under assignee
> Using same key reports different count of records for groupBy() and
> groupByKey() in Kafka Streaming Application
> ---
>
> Key: KAFKA-10475
> URL: https://issues.apache.org/jira/browse/KAFKA-10475
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 2.3.0
> Environment: Kafka Cluster:
> Kafka Version: kafka_2.12-2.6.0/
> openjdk version "1.8.0_265"
> Kafka Streams:
> Kafka Streams Version: 2.3.0
> openjdk version "11.0.8"
>Reporter: Saad Rasool
>Priority: Major
>
>
> We are experiencing what amounts to “lost packets” in our stream processing
> when we use custom groupByKey() values. We have a single processor node, with
> a source topic from which we read packets, do a grouping and aggregation on
> that group, and output based on a computation that requires access to a
> statestore.
>
> Let me give greater details of the problem and how we have tried to
> understand it until now, below:
> *Overview* We are setting up a Kafka Streams application in which we have to
> perform windowed operations. We are grouping devices based on a specific key.
> Following are the sample columns we are using for GroupBy:
>
> ||Field Name ||Field Value||
> |A|12|
> |B|abc|
> |C|x13|
>
> Sample Key based on the above data: 12abcx13 where key = Field (A) + Field
> (B) + Field (C)
> *Problem* Getting a different count of records in two scenarios against the
> same key When specifying the key ourselves using groupBy() Using groupByKey()
> to group the data on the ‘Input Kafka Topic’ partitioning key.
> *Description* We were first using the groupBy() function of Kafka streams to
> group the devices using the key above. In this case, the streams application
> dropped several records and produced less number of records than expected.
> However, when we did not specify our own custom grouping using the groupBy()
> function, and instead used groupByKey() to key the data on the original
> incoming Kafka partition key, we got the exact number of records which were
> expected.
> To check that we were using the exact same keys as the input topic for our
> custom groupBy() function we compared both Keys within the code. The Input
> topic key and the custom key were exactly the same.
> So now we have come to the conclusion that there is some internal
> functionality of the groupBy function that we are not able to understand
> because of which the groupBy function and the groupByKey function both report
> different counts for the same key. We have searched multiple forums but are
> unable to understand the reason for this phenomenon.
> *Code Snippet:*
> With groupBykey()
>
> {code:java}
> KStream myStream = this.stream
> .groupByKey()
> .windowedBy(TimeWindows.of(Duration.ofMinutes(windowTime)).advanceBy(Duration.ofMinutes(advanceByTime)).grace(Duration.ofSeconds(gracePeriod)))
> .reduce((value1, value2) -> value2)
> .suppress(Suppressed.untilWindowCloses(Suppressed.BufferConfig.unbounded()))
> .toStream() .transform(new myTransformer(this.store.name(),
> this.store.name());{code}
>
>
> With groupBy():
>
> {code:java}
> KStream myStream = this.stream
> .groupBy((key, value) -> value.A + value.B + value.C,
> Grouped.with(Serdes.String(), SerdesCollection.getInputSerdes()))
> .windowedBy(TimeWindows.of(Duration.ofMinutes(windowTime)).advanceBy(Duration.ofMinutes(advanceByTime)).grace(Duration.ofSeconds(gracePeriod)))
> .reduce((value1, value2) -> value2)
> .suppress(Suppressed.untilWindowCloses(Suppressed.BufferConfig.unbounded()))
> .toStream() .transform(new myTransformer(this.store.name()),
> this.store.name());{code}
>
>
> ||*Kafka Cluster Setup*|| ||
> |Number of Nodes| 3|
> |CPU Cores| 2|
> |RAM| 8 Gb|
>
> ||*Streaming Application Setup*||Version||
> | {{Kafka Streams Version }}| {{2.3.0}}|
> | openjdk version| 11.0.8|
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KAFKA-10475) Using same key reports different count of records for groupBy() and groupByKey() in Kafka Streaming Application
[
https://issues.apache.org/jira/browse/KAFKA-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195112#comment-17195112
]
Divya Guduru commented on KAFKA-10475:
--
I would like to work on this issue.. can someone update my name under assignee
> Using same key reports different count of records for groupBy() and
> groupByKey() in Kafka Streaming Application
> ---
>
> Key: KAFKA-10475
> URL: https://issues.apache.org/jira/browse/KAFKA-10475
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 2.3.0
> Environment: Kafka Cluster:
> Kafka Version: kafka_2.12-2.6.0/
> openjdk version "1.8.0_265"
> Kafka Streams:
> Kafka Streams Version: 2.3.0
> openjdk version "11.0.8"
>Reporter: Saad Rasool
>Priority: Major
>
>
> We are experiencing what amounts to “lost packets” in our stream processing
> when we use custom groupByKey() values. We have a single processor node, with
> a source topic from which we read packets, do a grouping and aggregation on
> that group, and output based on a computation that requires access to a
> statestore.
>
> Let me give greater details of the problem and how we have tried to
> understand it until now, below:
> *Overview* We are setting up a Kafka Streams application in which we have to
> perform windowed operations. We are grouping devices based on a specific key.
> Following are the sample columns we are using for GroupBy:
>
> ||Field Name ||Field Value||
> |A|12|
> |B|abc|
> |C|x13|
>
> Sample Key based on the above data: 12abcx13 where key = Field (A) + Field
> (B) + Field (C)
> *Problem* Getting a different count of records in two scenarios against the
> same key When specifying the key ourselves using groupBy() Using groupByKey()
> to group the data on the ‘Input Kafka Topic’ partitioning key.
> *Description* We were first using the groupBy() function of Kafka streams to
> group the devices using the key above. In this case, the streams application
> dropped several records and produced less number of records than expected.
> However, when we did not specify our own custom grouping using the groupBy()
> function, and instead used groupByKey() to key the data on the original
> incoming Kafka partition key, we got the exact number of records which were
> expected.
> To check that we were using the exact same keys as the input topic for our
> custom groupBy() function we compared both Keys within the code. The Input
> topic key and the custom key were exactly the same.
> So now we have come to the conclusion that there is some internal
> functionality of the groupBy function that we are not able to understand
> because of which the groupBy function and the groupByKey function both report
> different counts for the same key. We have searched multiple forums but are
> unable to understand the reason for this phenomenon.
> *Code Snippet:*
> With groupBykey()
>
> {code:java}
> KStream myStream = this.stream
> .groupByKey()
> .windowedBy(TimeWindows.of(Duration.ofMinutes(windowTime)).advanceBy(Duration.ofMinutes(advanceByTime)).grace(Duration.ofSeconds(gracePeriod)))
> .reduce((value1, value2) -> value2)
> .suppress(Suppressed.untilWindowCloses(Suppressed.BufferConfig.unbounded()))
> .toStream() .transform(new myTransformer(this.store.name(),
> this.store.name());{code}
>
>
> With groupBy():
>
> {code:java}
> KStream myStream = this.stream
> .groupBy((key, value) -> value.A + value.B + value.C,
> Grouped.with(Serdes.String(), SerdesCollection.getInputSerdes()))
> .windowedBy(TimeWindows.of(Duration.ofMinutes(windowTime)).advanceBy(Duration.ofMinutes(advanceByTime)).grace(Duration.ofSeconds(gracePeriod)))
> .reduce((value1, value2) -> value2)
> .suppress(Suppressed.untilWindowCloses(Suppressed.BufferConfig.unbounded()))
> .toStream() .transform(new myTransformer(this.store.name()),
> this.store.name());{code}
>
>
> ||*Kafka Cluster Setup*|| ||
> |Number of Nodes| 3|
> |CPU Cores| 2|
> |RAM| 8 Gb|
>
> ||*Streaming Application Setup*||Version||
> | {{Kafka Streams Version }}| {{2.3.0}}|
> | openjdk version| 11.0.8|
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (KAFKA-10472) Consider migrating Topology methods to the Builder pattern
[
https://issues.apache.org/jira/browse/KAFKA-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalpitha Karamadi reassigned KAFKA-10472:
-
Assignee: Kalpitha Karamadi
> Consider migrating Topology methods to the Builder pattern
> --
>
> Key: KAFKA-10472
> URL: https://issues.apache.org/jira/browse/KAFKA-10472
> Project: Kafka
> Issue Type: Improvement
> Components: streams
>Reporter: John Roesler
>Assignee: Kalpitha Karamadi
>Priority: Minor
> Labels: need-kip
>
> During code review for KIP-478, I got this feedback from [~bbejeck] .
> In Topology, we have methods like this:
> {code:java}
> public synchronized Topology addGlobalStore(
> final StoreBuilder storeBuilder,
> final String sourceName,
> final TimestampExtractor timestampExtractor,
> final Deserializer keyDeserializer,
> final Deserializer valueDeserializer,
> final String topic,
> final String processorName,
> final ProcessorSupplier stateUpdateSupplier){code}
> It would probably be better UX to preset a builder interface like:
> {code:java}
> public synchronized Topology addGlobalStore(
> AddGlobalStoreParameters.fromStoreBuilder(storeBuiler)
> .withSourceName(sourceName)
> .withSourceTopic(topic)
> .withTimestampExtractor(timestampExtractor)
> .withKeyDeserializer(keyDeserializer)
> .withValueDeserializer(valueDeserializer)
> .withProcessorName(processorName)
> .withStateUpdateSupplier(stateUpdateSupplier)
> ){code}
>
> Note: new API design proposals should take into account the proposed grammar:
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+DSL+Grammar
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [kafka] khaireddine120 commented on pull request #9207: Minor remove semicolon
khaireddine120 commented on pull request #9207: URL: https://github.com/apache/kafka/pull/9207#issuecomment-691693535 welcome, i will try to participate more in the future ;) 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
[GitHub] [kafka] ijuma opened a new pull request #9282: MINOR: Update junit to 5.7.0
ijuma opened a new pull request #9282: URL: https://github.com/apache/kafka/pull/9282 The final release is now out: https://junit.org/junit5/docs/5.7.0/release-notes/index.html ### 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
[GitHub] [kafka] dongjinleekr commented on pull request #8117: KAFKA-8403: Suppress needs a Materialized variant
dongjinleekr commented on pull request #8117: URL: https://github.com/apache/kafka/pull/8117#issuecomment-691669168 Rebased onto the latest trunk. 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
[GitHub] [kafka] dongjinleekr commented on pull request #7898: KAFKA-9366: Change log4j dependency into log4j2
dongjinleekr commented on pull request #7898: URL: https://github.com/apache/kafka/pull/7898#issuecomment-691668375 Rebased onto the lastest trunk, with including Sliding window support. @ijuma Could you have a look? 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
[GitHub] [kafka] dongjinleekr commented on pull request #7891: MINOR: Group KafkaController, ReplicaManager metrics in documentation
dongjinleekr commented on pull request #7891: URL: https://github.com/apache/kafka/pull/7891#issuecomment-691631850 Rebased onto the latest trunk. cc/ @hachikuji 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
