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

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

[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:

[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 >

[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 > - > >

[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

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

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

[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

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...]

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

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

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

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 >

[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

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

[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 >

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 >