Re: [VOTE] KIP-653: Upgrade log4j to log4j2

As of present: - Binding: +2 (Gwen, John) - Non-binding: +1 (David) Now we need one more binding +1. Thanks, Dongjin On Wed, Oct 7, 2020 at 1:37 AM David Jacot wrote: > Thanks for driving this, Dongjin! > > The KIP looks good to me. I’m +1 (non-binding). > > Best, > David > > Le mar. 6 oct.

Re: [DISCUSS] KIP-406: GlobalStreamThread should honor custom reset policy

Sorry I'm late to the party. Matthias raised a point to me regarding the recent development of moving restoration from stream threads to separate restore threads and allowing the stream threads to process any processible tasks even when some other tasks are still being restored by the restore

Jenkins build is back to normal : Kafka » kafka-trunk-jdk15 #150

See

Build failed in Jenkins: Kafka » kafka-2.5-jdk8 #15

See Changes: [Randall Hauch] KAFKA-10188: Prevent SinkTask::preCommit from being called after SinkTask::stop (#8910) -- [...truncated 3.10 MB...]

Jenkins build is back to normal : Kafka » kafka-trunk-jdk8 #117

See

Re: [DISCUSS] KIP-508: Make Suppression State Queriable - rebooted.

Hi Dongjin, Yes, those were the APIs I was thinking of. I honestly didn’t think of it until now. Sorry about that. I agree, a POC implementation would help us to see if this is a good choice for the kip. Thanks! John On Tue, Oct 6, 2020, at 10:21, Dongjin Lee wrote: > You mean, the

Re: KIP-675: Convert KTable to a KStream using the previous value

Thanks for the KIP. I am not sure if I understand the motivation. In particular the KIP says: > The main problem, apart from needing more code, is that if the same event is > received twice at the same time and the commit time is not 0, the difference > is deleted and nothing is emitted. Can

Re: [VOTE] KIP-584: Versioning scheme for features

Hi, Kowshik, Thanks for the follow up. Both look good to me. For 2, it would be useful to also add that an admin should make sure that no clients are using a deprecated feature version (e.g. using the client version metric) before deploying a release that deprecates it. Thanks, Jun On Tue,

Re: [DISCUSS] KIP-631: The Quorum-based Kafka Controller

Hi, Colin, Thanks for the reply. Made another pass of the KIP. A few more comments below. 55. We discussed earlier why the current behavior where we favor the current broker registration is better. Have you given this more thought? 80. Config related. 80.1 Currently, each broker only has the

Re: [DISCUSS] Apache Kafka 2.7.0 release

Hi Bill, Regarding KIP-612, only the first half of the KIP will get into 2.7 release: Broker-wide and per-listener connection rate limits, including corresponding configs and metric (KAFKA-10023). I see that the table in the release plan tags KAFKA-10023 as "old", not sure what it refers to. Note

Re: [VOTE] KIP-584: Versioning scheme for features

Hi Jun, I have added the following details in the KIP-584 write up: 1. Deployment, IBP deprecation and avoidance of double rolls. This section talks about the various phases of work that would be required to use this KIP to eventually avoid Broker double rolls in the cluster (whenever IBP values

Build failed in Jenkins: Kafka » kafka-trunk-jdk15 #149

See Changes: [github] MINOR: Refactor unit tests around RocksDBConfigSetter (#9358) [github] KAFKA-10527; Voters should not reinitialize as leader in same epoch (#9348) [github] KAFKA-10338;

Jenkins build is back to normal : Kafka » kafka-trunk-jdk11 #118

See

Re: [DISCUSS] Apache Kafka 2.7.0 release

Hi Kowshik, Given that the new feature is contained in the PR and the tooling is follow-on work (minor work, but that's part of the submitted PR), I think this is fine. Thanks, BIll On Tue, Oct 6, 2020 at 5:00 PM Kowshik Prakasam wrote: > Hey Bill, > > For KIP-584

Re: [DISCUSS] Apache Kafka 2.7.0 release

Hey Bill, For KIP-584 , we are in the process of reviewing/merging the write path PR into AK trunk: https://github.com/apache/kafka/pull/9001 . As far as the KIP goes, this PR is a major milestone. The PR merge will hopefully be done before EOD

[jira] [Created] (KAFKA-10580) Add topic ID support to Fetch request

Justine Olshan created KAFKA-10580: -- Summary: Add topic ID support to Fetch request Key: KAFKA-10580 URL: https://issues.apache.org/jira/browse/KAFKA-10580 Project: Kafka Issue Type:

Build failed in Jenkins: Kafka » kafka-trunk-jdk8 #116

See Changes: [github] MINOR: Refactor unit tests around RocksDBConfigSetter (#9358) [github] KAFKA-10527; Voters should not reinitialize as leader in same epoch (#9348)

[jira] [Created] (KAFKA-10579) Flaky test connect.integration.InternalTopicsIntegrationTest.testStartWhenInternalTopicsCreatedManuallyWithCompactForBrokersDefaultCleanupPolicy

Sophie Blee-Goldman created KAFKA-10579: --- Summary: Flaky test connect.integration.InternalTopicsIntegrationTest.testStartWhenInternalTopicsCreatedManuallyWithCompactForBrokersDefaultCleanupPolicy Key: KAFKA-10579

[jira] [Resolved] (KAFKA-10338) Support PEM format for SSL certificates and private key

[ https://issues.apache.org/jira/browse/KAFKA-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram resolved KAFKA-10338. Fix Version/s: 2.7.0 Reviewer: Manikumar Resolution: Fixed > Support PEM

Build failed in Jenkins: Kafka » kafka-2.6-jdk8 #28

See Changes: [Konstantine Karantasis] MINOR: Annotate test BlockingConnectorTest as integration test (#9379) -- [...truncated 3.15 MB...]

Build failed in Jenkins: Kafka » kafka-trunk-jdk11 #117

See Changes: [github] MINOR: Annotate test BlockingConnectorTest as integration test (#9379) [github] KAFKA-6733: Printing additional ConsumerRecord fields in DefaultMessageFormatter (#9099)

Build failed in Jenkins: Kafka » kafka-trunk-jdk8 #115

See Changes: [github] MINOR: Annotate test BlockingConnectorTest as integration test (#9379) [github] KAFKA-6733: Printing additional ConsumerRecord fields in DefaultMessageFormatter (#9099)

[jira] [Resolved] (KAFKA-10527) Voters should always initialize as followers

[ https://issues.apache.org/jira/browse/KAFKA-10527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson resolved KAFKA-10527. - Resolution: Fixed > Voters should always initialize as followers >

Re: [VOTE] KIP-653: Upgrade log4j to log4j2

Thanks for driving this, Dongjin! The KIP looks good to me. I’m +1 (non-binding). Best, David Le mar. 6 oct. 2020 à 17:23, Dongjin Lee a écrit : > As of present: > > - Binding: +2 (Gwen, John) > - Non-binding: 0 > > Thanks, > Dongjin > > On Sat, Oct 3, 2020 at 10:51 AM John Roesler wrote: >

Re: [VOTE] KIP-653: Upgrade log4j to log4j2

As of present: - Binding: +2 (Gwen, John) - Non-binding: 0 Thanks, Dongjin On Sat, Oct 3, 2020 at 10:51 AM John Roesler wrote: > Thanks for the KIP, Dongjin! > > I’ve just reviewed the KIP document, and it looks good to me. > > I’m +1 (binding) > > Thanks, > John > > On Fri, Oct 2, 2020, at

Re: [DISCUSS] KIP-508: Make Suppression State Queriable - rebooted.

You mean, the performance issue related to `#all` or `#range` query. Right? I reviewed the second approach (i.e., extending `ValueGetter`), and this approach is worth trying. Since KIP-508 was dropped from 2.7.0 release, we have enough time now. Let me have a try. I think we can have a rough one

KIP-675: Convert KTable to a KStream using the previous value

Hi all, I'd like to propose these changes to the Kafka Streams API. https://cwiki.apache.org/confluence/display/KAFKA/KIP-675%3A+Convert+KTable+to+a+KStream+using+the+previous+value This is a proposal to convert a KTable to a KStream knowing the previous value of the registry. I also opened a

Jenkins build is back to normal : Kafka » kafka-trunk-jdk15 #147

See

[jira] [Created] (KAFKA-10578) KIP-675: Convert KTable to a KStream using the previous value

Javier Freire Riobó created KAFKA-10578: --- Summary: KIP-675: Convert KTable to a KStream using the previous value Key: KAFKA-10578 URL: https://issues.apache.org/jira/browse/KAFKA-10578 Project:

Build failed in Jenkins: Kafka » kafka-trunk-jdk11 #116

See Changes: [github] MINOR: Fix failing test due to KAFKA-10556 PR (#9372) -- [...truncated 3.36 MB...]

Build failed in Jenkins: Kafka » kafka-trunk-jdk8 #114

See Changes: [github] MINOR: Fix failing test due to KAFKA-10556 PR (#9372) -- [...truncated 3.33 MB...] org.apache.kafka.streams.TopologyTestDriverTest >

Re: [DISCUSS] KIP-660: Pluggable ReplicaAssignor

Hi Efe, Thanks for the feedback. We also need to assign replicas when adding partitions to an existing topic. This is why I choose to use a list of partition ids. Otherwise we'd need the number of partitions and the starting partition id. Let me know if you have more questions On Tue, Oct 6,

Re: Kafka/Zookeeper

Hi Tom, It's not that Kafka 2.4.0 _requires_ Zookeeper 3.5.7. Rather, previous versions of Zookeeper suffered from security vulnerabilities and when Red Hat were preparing our product based on Kafka 2.4.0 the decision was taken to ship Zookeeper 3.5.7 to avoid those vulnerabilities. IIRC 3.5.7