Re: Proposal for EmbeddedKafkaCluster: Support JUnit 5 Extension in addition to JUnit 4 Rule

Thanks for the response John. I should point out that for streams app testing, we generally do use the TopologyTestDriver and it is much appreciated. We use EmbeddedKafkaCluster more for testing code that uses the Producer/Consumer clients. Regarding using something like maven-exec, I'm just no

[jira] [Resolved] (KAFKA-9261) NPE when updating client metadata

[ https://issues.apache.org/jira/browse/KAFKA-9261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar resolved KAFKA-9261. -- Resolution: Fixed > NPE when updating client metadata > - > >

Re: [kafka-clients] [VOTE] 2.4.0 RC3

Hi all, We have merged the PR for KAFKA-9212. Thanks to Jason for the fixing the issue. Thanks to Yannick for reporting the issue and Michael Jaschob for providing extra details. I am canceling this vote and will create new RC shortly. Thanks, Manikumar On Sat, Dec 7, 2019 at 3:19 AM Israel Ekp

[VOTE] 2.4.0 RC4

Hello Kafka users, developers and client-developers, This is the fifth candidate for release of Apache Kafka 2.4.0. This release includes many new features, including: - Allow consumers to fetch from closest replica - Support for incremental cooperative rebalancing to the consumer rebalance proto

[jira] [Reopened] (KAFKA-9261) NPE when updating client metadata

[ https://issues.apache.org/jira/browse/KAFKA-9261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar reopened KAFKA-9261: -- > NPE when updating client metadata > - > > Key: KAFKA-9261

[jira] [Reopened] (KAFKA-9212) Keep receiving FENCED_LEADER_EPOCH while sending ListOffsetRequest

[ https://issues.apache.org/jira/browse/KAFKA-9212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar reopened KAFKA-9212: -- > Keep receiving FENCED_LEADER_EPOCH while sending ListOffsetRequest >

Re: [DISCUSS] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

Hi Guozhang, Thanks for the feedback! On Sun, Dec 8, 2019 at 6:25 PM Guozhang Wang wrote: > 1. The addition of *metadata.expiry.ms *should > be included in the public interface. Also its semantics needs more > clarification (since previously it is hard-coded internal

[jira] [Resolved] (KAFKA-9241) SASL Clients are not forced to re-authenticate if they don't leverage SaslAuthenticateRequest

[ https://issues.apache.org/jira/browse/KAFKA-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram resolved KAFKA-9241. --- Fix Version/s: 2.5.0 Reviewer: Rajini Sivaram Resolution: Fixed > SASL Client

Re: [DISCUSS] KIP-435: Internal Partition Reassignment Batching

Hi Viktor, Thanks for the thoughtful reply. I'm actually not a PMC on the Apache Kafka project, although I hope to become one in the future :) In any case, the tasks that the PMC tackles tend to be more related to things like project policies, committers, legal stuff, brand stuff, and so on.

Re: [DISCUSS] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

Hello Brian, Thanks for your explanation, could you then update the wiki page for the algorithm part since when I read it, I thought it was different from the above, e.g. urgent topics should not be added just because of max.age expiration, but should only be added if there are sending data pendin

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

See Changes: [ismael] KAFKA-9212; Ensure LeaderAndIsr state updated in controller context -- [...truncated 2.94 MB...] org.apache.kafka.streams.internals.WindowStoreFacadeTe

Re: [DISCUSS] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

Hi Guozhang, I see, we agree on the topic threshold not applying to urgent topics, but differ slightly on what should be considered urgent. I would argue that we should consider topics nearing the metadata.max.age.ms to be urgent since they may still be well within the metadata.expiry.ms. That is,

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

See Changes: -- [...truncated 2.94 MB...] org.apache.kafka.streams.TestTopicsTest > testKeyValuesToMap STARTED org.apache.kafka.streams.TestTopicsTest > testKeyValuesToMap PASSED org.ap

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

See Changes: [bbejeck] MINOR: Fix javadoc of `flatTransform()` (#7803) -- [...truncated 8.33 MB...] org.apache.kafka.streams.TopologyTestDriverTest > shouldProcessRecord

[jira] [Created] (KAFKA-9288) Do not allow the same object to be inserted multiple times into ImplicitLinkedHashCollection

Colin McCabe created KAFKA-9288: --- Summary: Do not allow the same object to be inserted multiple times into ImplicitLinkedHashCollection Key: KAFKA-9288 URL: https://issues.apache.org/jira/browse/KAFKA-9288

[jira] [Resolved] (KAFKA-9212) Keep receiving FENCED_LEADER_EPOCH while sending ListOffsetRequest

[ https://issues.apache.org/jira/browse/KAFKA-9212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma resolved KAFKA-9212. Resolution: Fixed > Keep receiving FENCED_LEADER_EPOCH while sending ListOffsetRequest > --

Re: [DISCUSS] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

Sounds good, I agree that should not make a big difference in practice. On Mon, Dec 9, 2019 at 2:07 PM Brian Byrne wrote: > Hi Guozhang, > > I see, we agree on the topic threshold not applying to urgent topics, but > differ slightly on what should be considered urgent. I would argue that we > sh

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

See Changes: [github] KAFKA-9212; Ensure LeaderAndIsr state updated in controller context -- [...truncated 2.94 MB...] kafka.log.ProducerStateManagerTest > testAppendTxnMark

Re: [VOTE] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

With the concluded summary on the other discussion thread, I'm +1 on the proposal. Thanks Brian! On Tue, Nov 19, 2019 at 8:00 PM deng ziming wrote: > > > > For new (uncached) topics, one problem here is that we don't know which > > partition to map a record to in the event that it has a key or