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

See Changes: [wangguoz] KAFKA-8392: Fix old metrics leakage by brokers that have no leadership -- [...truncated 2.56 MB...]

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

See Changes: [cmccabe] KAFKA-8435: replace delete groups request/response with automated -- Started by an SCM change Started by an SCM change Started by an SCM change

Re: [DISCUSS] KIP-491: Preferred Leader Deprioritized List (Temporary Blacklist)

Hi Satish, Thanks for the reviews and feedbacks. > > The following is the requirements this KIP is trying to accomplish: > This can be moved to the"Proposed changes" section. Updated the KIP-491.  > >>The logic to determine the priority/order of which broker should be > preferred leader should

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

Thanks for driving the KIP. I agree that users need to be able to specify a partitioning strategy. Sophie raises a fair point about topic configs and producer configs. My take is, that consider `Repartitioned` as an "extension" to `Produced`, that adds topic configuration, is a good way to think

Re: [DISCUSS] KIP-491: Preferred Leader Deprioritized List (Temporary Blacklist)

Hi Stanislav, Thanks for taking time to do the review and feedbacks.   The Preferred Leader "Blacklist" feature is meant to be temporary in most use cases listed (I will explain a case which might need to be "permanent" below). It's a quick/easy way for the on-call engineer to take away

Re: [DISCUSS] KIP-447: Producer scalability for exactly once semantics

Boyang, thanks for the updated proposal! 3.a. As Jason mentioned, with EOS enabled we still need to augment the offset fetch request with a boolean to indicate "give me an retriable error code if there's pending offset, rather than sending me the committed offset immediately". Personally I still

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

Totally agree. I think in KStream interface it makes sense to have some duplicate configurations between operators in order to keep API simple and usable. Also, as more surface API has, harder it is to have proper backward compatibility. While initial idea of keeping topic level configs

[jira] [Resolved] (KAFKA-8392) Kafka broker leaks metric when partition leader moves to another node.

[ https://issues.apache.org/jira/browse/KAFKA-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang resolved KAFKA-8392. -- Resolution: Fixed Fix Version/s: 2.4.0 > Kafka broker leaks metric when partition

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

I think that is a good point about trying to keep producer level configurations and (repartition) topic level considerations separate. Number of partitions is definitely purely a topic level configuration. But on some level, serdes and partitioners are just as much a topic configuration as a

Re: [DISCUSS] KIP-466: Add support for List serialization and deserialization

Good point. I guess the simplest solution is, to actually add >> default.list.key/value.serde.type >> default.list.key/value.serde.inner to both `CommonClientConfigs` and `StreamsConfig`. It's not super clean, but I think it's the best we can do. Thoughts? -Matthias On 7/19/19 1:23 PM,

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

Hi Bill, Thanks a lot for the feedback. Yes, that makes sense. I’ve updated KIP with `Repartitioned#partitioner` configuration. In the beginning, I wanted to introduce a class for topic level configuration and keep topic level and producer level configurations (such as Produced) separately

[jira] [Resolved] (KAFKA-8663) partition assignment would be better original_assignment + new_reassignment during reassignments

[ https://issues.apache.org/jira/browse/KAFKA-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] GEORGE LI resolved KAFKA-8663. -- Resolution: Won't Fix looks like RAR + OAR is required for KIP-455 to preserve the targetReplicas

Re: [DISCUSS] KIP-466: Add support for List serialization and deserialization

Hi Matthias, I agree, ConsumerConfig did not seem like a right place for these configurations. I’ll put them in ProducerConfig, ConsumerConfig, and StreamsConfig. However, I have a question. What should I do in "configure(Map configs, boolean isKey)” methods? Which configurations should I try

[jira] [Created] (KAFKA-8693) Flakey test ErrorHandlingIntegrationTest #testSkipRetryAndDLQWithHeaders

Boyang Chen created KAFKA-8693: -- Summary: Flakey test ErrorHandlingIntegrationTest #testSkipRetryAndDLQWithHeaders Key: KAFKA-8693 URL: https://issues.apache.org/jira/browse/KAFKA-8693 Project: Kafka

[jira] [Created] (KAFKA-8692) Transient failure in kafka.api.SaslScramSslEndToEndAuthorizationTest.testNoDescribeProduceOrConsumeWithoutTopicDescribeAcl

Bill Bejeck created KAFKA-8692: -- Summary: Transient failure in kafka.api.SaslScramSslEndToEndAuthorizationTest.testNoDescribeProduceOrConsumeWithoutTopicDescribeAcl Key: KAFKA-8692 URL:

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

See Changes: [github] MINOR: Update documentation for enabling optimizations (#7099) [matthias] KAFKA-8513: Add kafka-streams-application-reset.bat for Windows platform

[jira] [Resolved] (KAFKA-8513) Add kafka-streams-application-reset.bat for Windows platform

[ https://issues.apache.org/jira/browse/KAFKA-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax resolved KAFKA-8513. Resolution: Fixed Fix Version/s: 2.4.0 > Add kafka-streams-application-reset.bat

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

See Changes: [bill] MINOR: Remove stale streams producer retry default docs. (#6844) [bill] MINOR: Update documentation for enabling optimizations (#7099) -- Started by an

Build failed in Jenkins: kafka-2.1-jdk8 #218

See Changes: [bill] MINOR: Remove stale streams producer retry default docs. (#6844) -- Started by an SCM change [EnvInject] - Loading node environment variables. Building

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

See Changes: [bbejeck] MINOR: Remove stale streams producer retry default docs. (#6844) -- Started by an SCM change [EnvInject] - Loading node environment variables.

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

See Changes: [bill] MINOR: Remove stale streams producer retry default docs. (#6844) -- Started by an SCM change [EnvInject] - Loading node environment variables. Building

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

Hi Lavani, Thanks for resurrecting this KIP. I'm also a +1 for adding a partition option. In addition to the reason provided by John, my reasoning is: 1. Users may want to use something other than hash-based partitioning 2. Users may wish to partition on something different than the key

Re: [VOTE] KIP-480 : Sticky Partitioner

Thanks everyone for reviewing and voting! I'm marking this KIP as accepted. There were 4 binding votes from Colin, Gwen, David and Bill, and 3 non-binding votes from Stanislav, M, and Mickael. There were no +0 or -1 votes. Thanks again, Justine On Fri, Jul 19, 2019 at 9:10 AM Bill Bejeck

Re: [VOTE] KIP-480 : Sticky Partitioner

Thanks for the KIP, looks like a great addition. +1 (binding) -Bill On Fri, Jul 19, 2019 at 5:55 AM Mickael Maison wrote: > +1 (non binding) > Thanks for the KIP! > > On Fri, Jul 19, 2019 at 2:23 AM David Arthur > wrote: > > > > +1 binding, looks like a nice improvement. Thanks! > > > >

Re: [VOTE] KIP-455: Create an Administrative API for Replica Reassignment

+1 (non-binding). Thanks for the KIP! On Thu, Jul 18, 2019 at 5:59 PM George Li wrote: > +1 (non-binding) > > > > Thanks for addressing the comments. > George > > On Thursday, July 18, 2019, 05:03:58 PM PDT, Gwen Shapira < > g...@confluent.io> wrote: > > Renewing my +1, thank you Colin

[jira] [Created] (KAFKA-8691) Flakey test ProcessorContextTest#shouldNotAllowToScheduleZeroMillisecondPunctuation

Boyang Chen created KAFKA-8691: -- Summary: Flakey test ProcessorContextTest#shouldNotAllowToScheduleZeroMillisecondPunctuation Key: KAFKA-8691 URL: https://issues.apache.org/jira/browse/KAFKA-8691

[jira] [Created] (KAFKA-8690) Flakey test ConnectWorkerIntegrationTest#testAddAndRemoveWorke

Boyang Chen created KAFKA-8690: -- Summary: Flakey test ConnectWorkerIntegrationTest#testAddAndRemoveWorke Key: KAFKA-8690 URL: https://issues.apache.org/jira/browse/KAFKA-8690 Project: Kafka

[jira] [Resolved] (KAFKA-8689) Cannot Name Join State Store Topics

[ https://issues.apache.org/jira/browse/KAFKA-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bejeck resolved KAFKA-8689. Resolution: Duplicate Duplicate of https://issues.apache.org/jira/browse/KAFKA-8558 > Cannot Name

Re: Stopping All Tasks When a New Connector Added

Hi Luying Would you be willing to make a PR to address this? It seems that you have already done most of the work. Thanks Adam On Thu, Jul 18, 2019 at 11:00 PM Liu Luying wrote: > Hi all, > I have noticed that Kafka Connect 2.3.0 will stop all existing tasks and > then start all the tasks,

Re: [DISCUSS] KIP-491: Preferred Leader Deprioritized List (Temporary Blacklist)

Thanks for the KIP. I have put my comments below. This is a nice improvement to avoid cumbersome maintenance. >> The following is the requirements this KIP is trying to accomplish: The ability to add and remove the preferred leader deprioritized list/blacklist. e.g. new ZK path/node or new

SchemaException: Error reading field 'topics'

I have a producer that would send messages to a topic with 4 partitions. Then, 4 consumers would consume from that topic. Most of the time, it works properly. But then, I would sometimes experience this error: org.apache.kafka.common.protocol.types.SchemaException: Error reading field 'topics':

Re: [DISCUSS] KIP-491: Preferred Leader Deprioritized List (Temporary Blacklist)

Hey George, Thanks for the KIP, it's an interesting idea. I was wondering whether we could achieve the same thing via the kafka-reassign-partitions tool. As you had also said in the JIRA, it is true that this is currently very tedious with the tool. My thoughts are that we could improve the

[jira] [Created] (KAFKA-8689) Cannot Name Join State Store Topics

Simon Dean created KAFKA-8689: - Summary: Cannot Name Join State Store Topics Key: KAFKA-8689 URL: https://issues.apache.org/jira/browse/KAFKA-8689 Project: Kafka Issue Type: Bug

[jira] [Created] (KAFKA-8688) Upgrade system tests fail due to data loss with older message format

Rajini Sivaram created KAFKA-8688: - Summary: Upgrade system tests fail due to data loss with older message format Key: KAFKA-8688 URL: https://issues.apache.org/jira/browse/KAFKA-8688 Project: Kafka

[jira] [Created] (KAFKA-8687) Pass store name when creating a Materialized using with(keySerde, valueSerde)

jmhostalet created KAFKA-8687: - Summary: Pass store name when creating a Materialized using with(keySerde, valueSerde) Key: KAFKA-8687 URL: https://issues.apache.org/jira/browse/KAFKA-8687 Project: Kafka

[jira] [Resolved] (KAFKA-8646) Materialized.withLoggingDisabled() does not disable changelog topics creation

[ https://issues.apache.org/jira/browse/KAFKA-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jmhostalet resolved KAFKA-8646. --- Resolution: Not A Bug > Materialized.withLoggingDisabled() does not disable changelog topics

Jira Cleanup

All, I left a few comments on some old but still open jiras in an attempt to clean up a little bit. Since probably no one would notice these comments I thought I'd quickly list them here to give people a chance to check on them: KAFKA-822 :

Re: [VOTE] KIP-480 : Sticky Partitioner

+1 (non binding) Thanks for the KIP! On Fri, Jul 19, 2019 at 2:23 AM David Arthur wrote: > > +1 binding, looks like a nice improvement. Thanks! > > -David > > On Wed, Jul 17, 2019 at 6:17 PM Justine Olshan wrote: > > > Hello all, > > > > I wanted to let you all know the KIP has been updated.

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

Hi John, In my mind it makes sense. If we add partitioner configuration to Repartitioned class, with the combination of specifying number of partitions for internal topics, user will have opportunity to ensure co-partitioning before join operation. I think this can be quite powerful feature.

Jenkins build is back to normal : kafka-2.3-jdk8 #75

See

Jenkins build is back to normal : kafka-trunk-jdk11 #705

See