Re: [DISCUSS] Should we automatically close stale PRs?

Hello, Matthias, Luke. > I agree with Matthias that contributors could and should help do more > "pre-review" PRs. I, personally, ready to do the initial review of PRs. Do we have some recipe to filter PRs that has potential to land in trunk? Can, you, please, send me list of PRs that need to

Re: [DISCUSS] KIP-812: Introduce another form of the `KafkaStreams.close()` API that forces the member to leave the consumer group

Hello Seung-chan, Thanks for the KIP writeup and summary! I made a pass on it and want to share some of my thoughts: On the very high level, we want to be able to effectively differentiate several cases as follows: 1) There's a network partition / soft failure hence clients cannot reach the

[jira] [Resolved] (KAFKA-13629) Client producer use faster ByteUtils sizeOfXxx algorithm

[ https://issues.apache.org/jira/browse/KAFKA-13629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luke Chen resolved KAFKA-13629. --- Fix Version/s: 3.2.0 Reviewer: Ismael Juma Resolution: Fixed > Client producer use

Re: Kafka <= 3.1 upgrade RocksDB to v6.27.3?

Hi Jonathan, I'm not against the idea of upgrading in 3.0.x and 3.1.x, assuming that the v6.27.3 version does not make any API or any semantic behavioral changes. But I can only speak for myself, not the whole community. For older versions as Bruno mentioned since there's compatibility issues we

Re: [DISCUSS] Should we automatically close stale PRs?

I agree with Matthias that contributors could and should help do more "pre-review" PRs. Otherwise, we're not fixing the root cause of the issue, and still keeping piling up the PRs (and auto closing them after stale) And I also agree with Guozhang that we should try to notify at least the

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #665

See

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.1 #74

See Changes: -- [...truncated 503158 lines...] [2022-02-07T01:22:00.993Z] [2022-02-07T01:22:00.993Z] KafkaZkClientTest > testDeletePath() PASSED [2022-02-07T01:22:00.993Z]

Re: [DISCUSS] KIP-818: Introduce cache-size-bytes-total Task Level Metric

Since the PR is reopened and we are going to re-merged the fixed PRs, what about just adding that as part of the KIP as the addendum? On Fri, Feb 4, 2022 at 2:13 AM Sagar wrote: > Thanks Sophie/Guozhang. > > Yeah I could have amended the KIP but it slipped my mind when Guozhang > proposed this

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #664

See Changes: -- [...truncated 512719 lines...] [2022-02-07T00:01:33.940Z] org.apache.kafka.streams.integration.TableTableJoinIntegrationTest > testInner[caching enabled =

[jira] [Resolved] (KAFKA-13563) FindCoordinatorFuture never get cleared in non-group mode( consumer#assign)

[ https://issues.apache.org/jira/browse/KAFKA-13563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang resolved KAFKA-13563. --- Fix Version/s: 3.2.0 3.1.1 Resolution: Fixed >

Re: [DISCUSS] Should we automatically close stale PRs?

Thanks for bringing this up David. I'm in favor of some automatic ways to clean up stale PRs. More specifically: * I think there are indeed many root causes why we have so many stale PRs that we should consider, and admittedly the reviewing manpower cannot keep up with the contributing pace is a

Re: [DISCUSS] Should we automatically close stale PRs?

I am +1 to close stale PRs -- not sure to what extend we want to automate it, or just leave it up to the committers to do the cleanup manually. I am happy both ways. However, I also want to point out, that one reason why we have so many stale PRs is the committer overload to actually review

Re: Mirror Maker Issue : Huge difference in topic size on disk

You could check whether the producers on the source cluster are using some compression algo. Use the same one on mm2 as currently it will decompress and then write again to the target cluster uncompressed unless you configure it. On Sun, Feb 6, 2022 at 05:20 Kafka Life wrote: > Dear Kafka

Mirror Maker Issue : Huge difference in topic size on disk

Dear Kafka Experts , Need your advice please I am running a mirror maker in kafka 2.8 to replicate a topic from kafka 0.11 instance. The size of each partition for a topic on 0.11 is always in 5 to 6 GB but the replicated topic in 2.8 instances is in 40 GB for the same partition. The topic