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

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on ubuntu-eu2 (ubuntu trusty) in workspace

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

See -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on

Build failed in Jenkins: kafka-trunk-jdk10 #563

See Changes: [wangguoz] KAFKA-7223: Add name config to Suppressed (#5731) [wangguoz] HOTFIX: Fix broken links (#5676) -- [...truncated 2.24 MB...]

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

See Changes: [github] MINOR: Docs on state store instantiation (#5698) -- [...truncated 508.07 KB...]

Build failed in Jenkins: kafka-trunk-jdk10 #562

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H30 (ubuntu xenial) in workspace

Re: [VOTE] KIP-349 Priorities for Source Topics

> On Oct 3, 2018, at 12:41 PM, Colin McCabe wrote: > > Will there be a separate code path for people who don't want to use this > feature? Yes, I tried to capture this in the KIP by indicating that this API change is 100% backwards compatible. Current consumer semantics and performance

Re: Incremental Cooperative Rebalancing

Konstantine, this is exciting work! Couple questions: I understand that, overall, rebalances would require less work and less time acquiring and releasing resources. But OTOH I believe individual consumers might see successive revokes/assigns while a rebalance settles. Is that right? And if so,

Build failed in Jenkins: kafka-trunk-jdk10 #561

See Changes: [wangguoz] KAFKA-7223: Make suppression buffer durable (#5724) [colin] KAFKA-6123: Give client MetricsReporter auto-generated client.id (#5383) [github] MINOR: Docs on state store instantiation

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

See Changes: [colin] MINOR: Increase timeout for starting JMX tool (#5735) [wangguoz] KAFKA-7223: Make suppression buffer durable (#5724) [colin] KAFKA-6123: Give client MetricsReporter auto-generated

[VOTE] KIP-376: Implement AutoClosable on appropriate classes that want to be used in a try-with-resource statement

Hi All, I want to start a voting on this KIP: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=93325308 Here is the discussion thread: https://lists.apache.org/thread.html/9f6394c28d3d11a67600d5d7001e8aaa318f1ad497b50645654bbe3f@%3Cdev.kafka.apache.org%3E Thanks, Yishun

[jira] [Resolved] (KAFKA-7393) Consider making suppression node names independent of topologically numbered names.

[ https://issues.apache.org/jira/browse/KAFKA-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Roesler resolved KAFKA-7393. - Resolution: Won't Fix We realized that Suppressed needs to support a name parameter in keeping

[jira] [Created] (KAFKA-7477) Improve Streams close timeout semantics

John Roesler created KAFKA-7477: --- Summary: Improve Streams close timeout semantics Key: KAFKA-7477 URL: https://issues.apache.org/jira/browse/KAFKA-7477 Project: Kafka Issue Type: Improvement

Build failed in Jenkins: kafka-trunk-jdk10 #560

See Changes: [colin] MINOR: Increase timeout for starting JMX tool (#5735) -- [...truncated 2.24 MB...] org.apache.kafka.streams.test.OutputVerifierTest >

Re: Incremental Cooperative Rebalancing

Thanks for sharing! Excellent write up! -Matthias On 10/2/18 4:22 PM, Konstantine Karantasis wrote: > Hey everyone, > > I'd like to bring to your attention a general design document that was just > published in Apache Kafka's wiki space: > >

Re: [DISCUSSION] KIP-376: Implement AutoClosable on appropriate classes that has close()

Thanks for clarifying. I thought that if we inherit `close() throws Exception` we need to declare the same exception -- this would have been an issue. Thus, my backward compatibility concerns are resolved. About try-with-resources: I think, allowing to use try-with-resources is the core

Re: [DISCUSSION] KIP-376: Implement AutoClosable on appropriate classes that has close()

Hi Colin, Yes, I absolutely agree with you. We can implement an interface while throwing a subset of the possible checked exceptions, and empty set is also a subset-so we also don't have to throw an exception. And yes, you are right, I should emphasize the benefit of AutoCloseable in the KIP.

[DISCUSS] KIP-379: Multiple Consumer Group Management

Hello, friends! Welcome to the Multiple Consumer Group Management feature for kafka-consumer-groups utility discussion thread. KIP is available here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-379%3A+Multiple+Consumer+Group+Management Pull Request:

Re: Edit permissions for https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem

Done On 10/2/18 6:36 PM, Bill Mclane wrote: > User ID should be wmclane > > Thanks Matthias... > > Bill— > > William P. McLane > Messaging Evangelist > TIBCO Software > >> On Oct 2, 2018, at 8:31 PM, Matthias J. Sax wrote: >> >> Could not find your user -- please provide your wiki user ID so

Re: Re run build of a pull request

We don't know why it fails yet. We are investigating. If anyone knows, please share so we can fix it :) -Matthias On 10/3/18 9:07 AM, Kamal Chandraprakash wrote: > No need to push a commit to run the test case. Type "retest this please" as > comment. > It will again run all the test cases. >

Re: [DISCUSSION] KIP-376: Implement AutoClosable on appropriate classes that has close()

On Sun, Sep 30, 2018, at 13:19, Matthias J. Sax wrote: > Closeable is part of `java.io` while AutoClosable is part of > `java.lang`. Thus, the second one is more generic. Also, JavaDoc points > out that `Closable#close()` must be idempotent while > `AutoClosable#close()` can have side effects.

Re: Re run build of a pull request

No need to push a commit to run the test case. Type "retest this please" as comment. It will again run all the test cases. On Wed, Oct 3, 2018 at 1:12 PM Suman B N wrote: > Team, > > Every once in a while, PR builds fails due to below test failure with Null > Pointer Exception. > >-

Jenkins build is back to normal : kafka-trunk-jdk10 #559

See

Re: [VOTE] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection

Thanks for reminding me about the "Binding" vote Bill. I remember some people with non-binding vote, so jumped the gun a bit too early. We will wait for 2 more as you stated. Regards, On Wed, 3 Oct 2018 at 16:07, Bill Bejeck wrote: > +1 from me. > > As for closing the vote, it needs to be open

Re: [VOTE] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection

+1 from me. As for closing the vote, it needs to be open for a minimum of 72 and requires three binding +1 votes. Additionally, there needs more +1 binding votes than -1 votes. The description for the lazy majority vote process is described here

Re: [VOTE] KIP-372: Naming Repartition Topics for Joins and Grouping

All, One additional minor change "Grouped.named" has been changed to "Grouped.as". I've updated the KIP with this change. Thanks, Bill

[jira] [Resolved] (KAFKA-6632) Very slow hashCode methods in Kafka Connect types

[ https://issues.apache.org/jira/browse/KAFKA-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maciej Bryński resolved KAFKA-6632. --- Resolution: Fixed > Very slow hashCode methods in Kafka Connect types >

[jira] [Resolved] (KAFKA-6626) Performance bottleneck in Kafka Connect sendRecords

[ https://issues.apache.org/jira/browse/KAFKA-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maciej Bryński resolved KAFKA-6626. --- Resolution: Unresolved > Performance bottleneck in Kafka Connect sendRecords >

Re: [VOTE] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection

Since this has been open for a while, I am assuming that it's good to go? if so, I will update the KIP page - and start coding this. I would prefer re-using existing tests written for DefaultPartitioner, so that we don't need to write new tests. Regards, On Sun, 30 Sep 2018 at 19:34, Matthias

[jira] [Resolved] (KAFKA-3601) fail fast when newer client connecting to older server

[ https://issues.apache.org/jira/browse/KAFKA-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar resolved KAFKA-3601. -- Resolution: Fixed Closing in favour of newer releases.  Please reopen if you think otherwise > fail

[jira] [Resolved] (KAFKA-3484) Transient failure in SslConsumerTest.testListTopics

[ https://issues.apache.org/jira/browse/KAFKA-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar resolved KAFKA-3484. -- Resolution: Not A Problem Closing as testListTopics is moved to PlaintextConsumerTest. > Transient

[jira] [Resolved] (KAFKA-7429) Enable dynamic key/truststore update with same filename/password

[ https://issues.apache.org/jira/browse/KAFKA-7429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikumar resolved KAFKA-7429. -- Resolution: Fixed > Enable dynamic key/truststore update with same filename/password >

Re run build of a pull request

Team, Every once in a while, PR builds fails due to below test failure with Null Pointer Exception. - org.apache.kafka.streams.scala.kstream.KStreamTest.join 2 KStreams should join correctly records But locally it is successfully run. Sometimes, when re-run, it just passes. Now I have two

[jira] [Resolved] (KAFKA-7096) Consumer should drop the data for unassigned topic partitions

[ https://issues.apache.org/jira/browse/KAFKA-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin resolved KAFKA-7096. - Resolution: Fixed > Consumer should drop the data for unassigned topic partitions >

[jira] [Resolved] (KAFKA-6045) All access to log should fail if log is closed

[ https://issues.apache.org/jira/browse/KAFKA-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin resolved KAFKA-6045. - Resolution: Won't Fix > All access to log should fail if log is closed >

[jira] [Resolved] (KAFKA-5950) AdminClient should retry based on returned error codes

[ https://issues.apache.org/jira/browse/KAFKA-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin resolved KAFKA-5950. - Resolution: Fixed Per comment in the PR, it appears that the issue has been addressed in KAFKA-6299

[jira] [Resolved] (KAFKA-5857) Excessive heap usage on controller node during reassignment

[ https://issues.apache.org/jira/browse/KAFKA-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin resolved KAFKA-5857. - Resolution: Cannot Reproduce In general we need heapdump to investigate the issue. Since we don't have