Re: [VOTE] KIP-544: Make metrics exposed via JMX configurable

+1 (binding). Thanks for the KIP. On Sat, Nov 9, 2019 at 3:11 PM Alexandre Dupriez < alexandre.dupr...@gmail.com> wrote: > +1 (non-binding) > > Le ven. 8 nov. 2019 à 20:21, Bill Bejeck a écrit : > > > Thanks for the KIP, +1 (binding). > > > > -Bill > > > > On Fri, Nov 8, 2019 at 1:28 PM Gwen

[jira] [Created] (KAFKA-9167) Implement a broker to controller request channel

Viktor Somogyi-Vass created KAFKA-9167: -- Summary: Implement a broker to controller request channel Key: KAFKA-9167 URL: https://issues.apache.org/jira/browse/KAFKA-9167 Project: Kafka

Re: [VOTE] KIP-544: Make metrics exposed via JMX configurable

+1 (non-binding) Le ven. 8 nov. 2019 à 20:21, Bill Bejeck a écrit : > Thanks for the KIP, +1 (binding). > > -Bill > > On Fri, Nov 8, 2019 at 1:28 PM Gwen Shapira wrote: > > > +1 (binding) > > > > On Thu, Nov 7, 2019 at 11:17 AM Xavier Léauté > wrote: > > > > > > Hi everyone, > > > > > > I'd

Build failed in Jenkins: kafka-2.4-jdk8 #58

See Changes: [jason] KAFKA-9133; Cleaner should handle log start offset larger than active -- [...truncated 5.08 MB...] kafka.admin.ReassignPartitionsClusterTest >

Build failed in Jenkins: kafka-trunk-jdk8 #4028

See Changes: [donglin] KAFKA-9016; Warn when log dir stopped serving replicas [github] KAFKA-9098: When users name repartition topic, use the name for the [github] KAFKA-9133; Cleaner should handle log start

[jira] [Created] (KAFKA-9166) Implement MetadataFetch API

Viktor Somogyi-Vass created KAFKA-9166: -- Summary: Implement MetadataFetch API Key: KAFKA-9166 URL: https://issues.apache.org/jira/browse/KAFKA-9166 Project: Kafka Issue Type: Sub-task

Build failed in Jenkins: kafka-trunk-jdk8 #4029

See Changes: [manikumar] KAFKA-8984: Improve tagged fields documentation [jason] MINOR. Update Epoch field descrition in FetchRequest api doc (#7673) [manikumar] MINOR: Update docs about ZooKeeper upgrade

Build failed in Jenkins: kafka-2.4-jdk8 #59

See Changes: [manikumar] KAFKA-8984: Improve tagged fields documentation [jason] MINOR: Update Epoch field descrition in FetchRequest api doc (#7673) [manikumar] MINOR: Update docs about ZooKeeper upgrade issue

Re: Why standby tasks read from the StandbyTasks::checkpointedOffsets in assignStandbyPartitions()

Hello Navinder, Sorry for the late reply and thanks for bringing this up. I think this is indeed a bug that needs to be fixed. The rationale behind was the following: for restoring active tasks and processing standby tasks, we are using the same consumer client within the thread (the

Re: [DISCUSS] KIP-221: Repartition Topic Hints in Streams

Thanks for those thoughts, Matthias, I find your reasoning about the optimization behavior compelling. The `through` operation is very simple and clear to reason about. It just passes the data exactly at the specified point in the topology exactly through the specified topic. Likewise, if a user

Re: [DISCUSS] KIP-221: Repartition Topic Hints in Streams

> it seems like we do want to allow >> people to optionally specify a partition count as part of this >> operation, but we don't want that option to _force_ repartitioning Correct, ie, that is my suggestions. > "Use P partitions if repartitioning is necessary" I disagree here, because my

Build failed in Jenkins: kafka-2.4-jdk8 #60

See Changes: -- [...truncated 7.03 MB...] kafka.api.SslAdminClientIntegrationTest > testAclDescribe PASSED kafka.api.SslAdminClientIntegrationTest >

Build failed in Jenkins: kafka-2.3-jdk8 #134

See Changes: [jason] KAFKA-9133; Cleaner should handle log start offset larger than active -- [...truncated 2.96 MB...] kafka.log.LogCleanerTest > testPartialSegmentClean

Re: Subject: [VOTE] 2.2.2 RC2

Thanks for running the release Randall! - verified all signatures - build from source - ran unit/integration tests Latest system test passed, too: https://jenkins.confluent.io/job/apache-kafka-test/job/2.2/225/ +1 (binding) -Matthias On 11/8/19 3:11 PM, Bill Bejeck wrote: >- verified

Re: [DISCUSS] KIP-221: Repartition Topic Hints in Streams

Sorry for late reply. I guess, the question boils down to the intended semantics of `repartition()`. My understanding is as follows: - KS does auto-repartitioning for correctness reasons (using the upstream topic to determine the number of partitions) - KS does auto-repartitioning only for

[jira] [Created] (KAFKA-9168) Integrate JNI direct buffer support to RocksDBStore

Sagar Rao created KAFKA-9168: Summary: Integrate JNI direct buffer support to RocksDBStore Key: KAFKA-9168 URL: https://issues.apache.org/jira/browse/KAFKA-9168 Project: Kafka Issue Type: Task

Re: [DISCUSS] KIP-535: Allow state stores to serve stale reads during rebalance

I agree, that we might want to drop the time-base lag for the initial implementation. There is no good way to get this information without a broker side change. (100) For the offset lag information, I don't see a reason why the app should drive when this information is updated though, because