Re: [DISCUSS] Kafka 2.0.0 in June 2018

Hey everyone. Regarding the status of KIP-125, just a heads up: I have an implementation of KIP-125 (KAFKA-4513) here: https://github.com/onurkaraman/kafka/commit/3b5448006ab70ba2b0b5e177853d191d0f777452 The code might need to be rebased. The steps described in the KIP are a bit involved. Other

Re: [ANNOUNCE] New committer: Onur Karaman

gt; > > > On Nov 6, 2017, at 9:24 AM, Jun Rao <j...@confluent.io> wrote: > > > > > > Hi, everyone, > > > > > > The PMC of Apache Kafka is pleased to announce a new Kafka committer > Onur > > > Karaman. > > > > > > Onur's

Re: [VOTE] KIP-214: Add zookeeper.max.in.flight.requests config to the broker

to benchmark various defaults. > >> > >> On Mon, Oct 30, 2017 at 3:05 PM, Ismael Juma <isma...@gmail.com> wrote: > >> > >> > Thanks for the KIP, +1 (binding). > >> > > >> > On 27 Oct 2017 6:15 pm, "Onur Karaman" <onu

[VOTE] KIP-214: Add zookeeper.max.in.flight.requests config to the broker

I'd like to start the vote for KIP-214: Add zookeeper.max.in.flight.requests config to the broker https://cwiki.apache.org/confluence/display/KAFKA/KIP-214%3A+Add+zookeeper.max.in.flight.requests+config+to+the+broker - Onur

Re: [DISCUSS] KIP-213 Support non-key joining in KTable

Done. I changed my KIP to KIP-214. So this KIP doesn't need to change. On Wed, Oct 25, 2017 at 10:33 PM, Onur Karaman <onurkaraman.apa...@gmail.com > wrote: > Looks like Jan technically made his KIP wiki page first so I'll just > change my KIP number. > > On Wed, Oct 2

Re: [DISCUSS] KIP-213: Add zookeeper.max.in.flight.requests config to the broker

at 4:17 PM, Ted Yu <yuzhih...@gmail.com> wrote: > This is for KAFKA-5894, right ? > Please fill out the JIRA link. > > +1 on this proposal. > > On Wed, Oct 25, 2017 at 4:11 PM, Onur Karaman < > onurkaraman.apa...@gmail.com> > wrote: > > >

[DISCUSS] KIP-214: Add zookeeper.max.in.flight.requests config to the broker

Hey everyone. Giving this another shot since it looks like there was a KIP number collision on the wiki page. I made a config kip, KIP-214: Add zookeeper.max.in.flight.requests config to the broker:

Re: [DISCUSS] KIP-213 Support non-key joining in KTable

Looks like Jan technically made his KIP wiki page first so I'll just change my KIP number. On Wed, Oct 25, 2017 at 4:59 PM, Matthias J. Sax wrote: > Thanks a lot for the KIP. Can we please move the discussion to the dev > list? > > Thus, after fixing the KIP collision,

[DISCUSS] KIP-213: Add zookeeper.max.in.flight.requests config to the broker

Hey everyone. I made a config kip, KIP-213: Add zookeeper.max.in.flight.requests config to the broker: https://cwiki.apache.org/confluence/display/KAFKA/KIP-213%3A+Add+zookeeper.max.in.flight.requests+config+to+the+broker Comments are welcome. - Onur

[jira] [Created] (KAFKA-6082) consider fencing zookeeper updates with controller epoch zkVersion

Onur Karaman created KAFKA-6082: --- Summary: consider fencing zookeeper updates with controller epoch zkVersion Key: KAFKA-6082 URL: https://issues.apache.org/jira/browse/KAFKA-6082 Project: Kafka

[jira] [Created] (KAFKA-6081) response error code checking

Onur Karaman created KAFKA-6081: --- Summary: response error code checking Key: KAFKA-6081 URL: https://issues.apache.org/jira/browse/KAFKA-6081 Project: Kafka Issue Type: Sub-task

[jira] [Resolved] (KAFKA-5083) always leave the last surviving member of the ISR in ZK

[ https://issues.apache.org/jira/browse/KAFKA-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman resolved KAFKA-5083. - Resolution: Fixed This has been fixed in KAFKA-5642. > always leave the last surviving mem

[jira] [Created] (KAFKA-6065) Add zookeeper metrics to ZookeeperClient as in KIP-188

Onur Karaman created KAFKA-6065: --- Summary: Add zookeeper metrics to ZookeeperClient as in KIP-188 Key: KAFKA-6065 URL: https://issues.apache.org/jira/browse/KAFKA-6065 Project: Kafka Issue

[jira] [Created] (KAFKA-6014) new consumer mirror maker halts after committing offsets to a deleted topic

Onur Karaman created KAFKA-6014: --- Summary: new consumer mirror maker halts after committing offsets to a deleted topic Key: KAFKA-6014 URL: https://issues.apache.org/jira/browse/KAFKA-6014 Project

[jira] [Created] (KAFKA-5894) add the notion of max inflight requests to async ZookeeperClient

Onur Karaman created KAFKA-5894: --- Summary: add the notion of max inflight requests to async ZookeeperClient Key: KAFKA-5894 URL: https://issues.apache.org/jira/browse/KAFKA-5894 Project: Kafka

[jira] [Resolved] (KAFKA-4747) add metrics for KafkaConsumer.poll

[ https://issues.apache.org/jira/browse/KAFKA-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman resolved KAFKA-4747. - Resolution: Won't Fix [~junrao] pointed out that the distinction between tim-in-poll and time

[jira] [Resolved] (KAFKA-5703) allow debug-level logging for RequestChannel's request logger

[ https://issues.apache.org/jira/browse/KAFKA-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman resolved KAFKA-5703. - Resolution: Fixed Woops. Looks like [~ijuma] already fixed this 3 days ago

[jira] [Created] (KAFKA-5703) allow debug-level logging for RequestChannel's request logger

Onur Karaman created KAFKA-5703: --- Summary: allow debug-level logging for RequestChannel's request logger Key: KAFKA-5703 URL: https://issues.apache.org/jira/browse/KAFKA-5703 Project: Kafka

[jira] [Resolved] (KAFKA-5501) introduce async ZookeeperClient

[ https://issues.apache.org/jira/browse/KAFKA-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman resolved KAFKA-5501. - Resolution: Fixed > introduce async ZookeeperCli

[jira] [Created] (KAFKA-5642) use async ZookeeperClient everywhere

Onur Karaman created KAFKA-5642: --- Summary: use async ZookeeperClient everywhere Key: KAFKA-5642 URL: https://issues.apache.org/jira/browse/KAFKA-5642 Project: Kafka Issue Type: Sub-task

Re: [DISCUSS] KIP-175: Additional '--describe' views for ConsumerGroupCommand

In other words, I think the default should be the exact behavior we have today plus the remaining group information from DescribeGroupResponse. On Fri, Jul 14, 2017 at 11:36 AM, Onur Karaman <onurkaraman.apa...@gmail.com > wrote: > I think if we had the opportunity to start fro

Re: [DISCUSS] KIP-175: Additional '--describe' views for ConsumerGroupCommand

I think if we had the opportunity to start from scratch, --describe would have been the following: --describe --offsets: shows all offsets committed for the group as well as lag --describe --state (or maybe --members): shows the full DescribeGroupResponse output (including things like generation

[jira] [Created] (KAFKA-5502) read current brokers from zookeeper upon processing broker change

Onur Karaman created KAFKA-5502: --- Summary: read current brokers from zookeeper upon processing broker change Key: KAFKA-5502 URL: https://issues.apache.org/jira/browse/KAFKA-5502 Project: Kafka

[jira] [Created] (KAFKA-5501) use async zookeeper apis everywhere

Onur Karaman created KAFKA-5501: --- Summary: use async zookeeper apis everywhere Key: KAFKA-5501 URL: https://issues.apache.org/jira/browse/KAFKA-5501 Project: Kafka Issue Type: Sub-task

Re: [VOTE] KIP-168: Add TotalTopicCount metric per cluster

+1 On Thu, Jun 22, 2017 at 10:05 AM, Dong Lin wrote: > Thanks for the KIP. +1 (non-binding) > > On Wed, Jun 21, 2017 at 1:17 PM, Abhishek Mendhekar < > abhishek.mendhe...@gmail.com> wrote: > > > Hi Kafka Dev, > > > > I did like to start the voting on - > >

Re: [DISCUSS] KIP-168: Add TotalTopicCount metric per cluster

This metric sounds simple and useful. +1 On Fri, Jun 16, 2017 at 9:09 AM, Abhishek Mendhekar < abhishek.mendhe...@gmail.com> wrote: > Hi Kafka Dev, > > I created KIP-168 to propose adding a metric to emit total topic count > in a cluster. The metric will be emited by the controller. > > The KIP

[jira] [Commented] (KAFKA-4595) Controller send thread can't stop when broker change listener event trigger for dead brokers

[ https://issues.apache.org/jira/browse/KAFKA-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035465#comment-16035465 ] Onur Karaman commented on KAFKA-4595: - [~ijuma] Yeah I think KAFKA-5028 solved this issue

[jira] [Commented] (KAFKA-1595) Remove deprecated and slower scala JSON parser from kafka.consumer.TopicCount

[ https://issues.apache.org/jira/browse/KAFKA-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035365#comment-16035365 ] Onur Karaman commented on KAFKA-1595: - Sounds good. > Remove deprecated and slower scala JSON par

[jira] [Comment Edited] (KAFKA-1595) Remove deprecated and slower scala JSON parser from kafka.consumer.TopicCount

[ https://issues.apache.org/jira/browse/KAFKA-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032276#comment-16032276 ] Onur Karaman edited comment on KAFKA-1595 at 6/1/17 12:50 AM: -- I think

[jira] [Commented] (KAFKA-1595) Remove deprecated and slower scala JSON parser from kafka.consumer.TopicCount

[ https://issues.apache.org/jira/browse/KAFKA-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032276#comment-16032276 ] Onur Karaman commented on KAFKA-1595: - I think [~ijuma]'s PR (https://github.com/apache/kafka/pull/83

Re: [DISCUSS] KIP-108: Create Topic Policy

@Colin checkout kafka.admin.ZkSecurityMigrator. This is what I meant in my earlier comment on "acl off zookeeper" On Tue, May 30, 2017 at 3:39 PM Colin McCabe wrote: > It seems like, to make it really secure, we need the enforcement to be > done at the ZooKepeer level. Any

Re: [DISCUSS] KIP-108: Create Topic Policy

Just for completeness, I think one option is to: 1. Upgrade broker-side auto topic creation to send CreateTopicsRequest. This is just to unify the topic creation flow and policy enforcement. 2. Migrate all clients away from topic creation from zookeeper and instead send CreateTopicsRequest 3. ACL

Re: KIP-162: Enable topic deletion by default

Would it make sense to resolve KAFKA-4893 before enabling it by default, as fixing the ticket would likely involve changing the log directory structure? On Fri, May 26, 2017 at 3:24 PM, Guozhang Wang wrote: > I'd say just remove those two lines. > > On Fri, May 26, 2017 at

[jira] [Commented] (KAFKA-5328) consider switching json parser from scala to jackson

[ https://issues.apache.org/jira/browse/KAFKA-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027086#comment-16027086 ] Onur Karaman commented on KAFKA-5328: - I copied the topic assignment znodes and partition state znodes

[jira] [Created] (KAFKA-5328) consider switching json parser from scala to jackson

Onur Karaman created KAFKA-5328: --- Summary: consider switching json parser from scala to jackson Key: KAFKA-5328 URL: https://issues.apache.org/jira/browse/KAFKA-5328 Project: Kafka Issue Type

[jira] [Updated] (KAFKA-5323) AdminUtils.createTopic should check topic existence upfront

[ https://issues.apache.org/jira/browse/KAFKA-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5323: Status: Patch Available (was: Open) > AdminUtils.createTopic should check topic existence upfr

[jira] [Commented] (KAFKA-5323) AdminUtils.createTopic should check topic existence upfront

[ https://issues.apache.org/jira/browse/KAFKA-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024223#comment-16024223 ] Onur Karaman commented on KAFKA-5323: - This can have a larger impact than one might initially suspect

[jira] [Created] (KAFKA-5323) AdminUtils.createTopic should check topic existence upfront

Onur Karaman created KAFKA-5323: --- Summary: AdminUtils.createTopic should check topic existence upfront Key: KAFKA-5323 URL: https://issues.apache.org/jira/browse/KAFKA-5323 Project: Kafka

[jira] [Updated] (KAFKA-5310) reset ControllerContext during resignation

[ https://issues.apache.org/jira/browse/KAFKA-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5310: Status: Patch Available (was: Open) > reset ControllerContext during resignat

[jira] [Updated] (KAFKA-5310) reset ControllerContext during resignation

[ https://issues.apache.org/jira/browse/KAFKA-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5310: Description: This ticket is all about ControllerContext initialization and teardown. The key

[jira] [Created] (KAFKA-5310) reset ControllerContext during resignation

Onur Karaman created KAFKA-5310: --- Summary: reset ControllerContext during resignation Key: KAFKA-5310 URL: https://issues.apache.org/jira/browse/KAFKA-5310 Project: Kafka Issue Type: Sub-task

[jira] [Commented] (KAFKA-4896) Offset loading can use more threads

[ https://issues.apache.org/jira/browse/KAFKA-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16020447#comment-16020447 ] Onur Karaman commented on KAFKA-4896: - handleGroupImmigration only gets called from handling

[jira] [Updated] (KAFKA-5258) move all partition and replica state transition rules into their states

[ https://issues.apache.org/jira/browse/KAFKA-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5258: Description: Today the PartitionStateMachine and ReplicaStateMachine defines and asserts the valid

[jira] [Updated] (KAFKA-5258) move all partition and replica state transition rules into their states

[ https://issues.apache.org/jira/browse/KAFKA-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5258: Description: Today the PartitionStateMachine and ReplicaStateMachine defines and asserts the valid

[jira] [Updated] (KAFKA-5258) move all partition and replica state transition rules into their states

[ https://issues.apache.org/jira/browse/KAFKA-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5258: Summary: move all partition and replica state transition rules into their states (was: move all

[jira] [Commented] (KAFKA-5261) Performance improvement of SimpleAclAuthorizer

[ https://issues.apache.org/jira/browse/KAFKA-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013665#comment-16013665 ] Onur Karaman commented on KAFKA-5261: - Would one alternative be to just make a CachedAclAuthorizer

[jira] [Updated] (KAFKA-5258) move all partition and replica state transition rules into a map

[ https://issues.apache.org/jira/browse/KAFKA-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5258: Status: Patch Available (was: In Progress) > move all partition and replica state transition ru

[jira] [Work started] (KAFKA-5258) move all partition and replica state transition rules into a map

[ https://issues.apache.org/jira/browse/KAFKA-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-5258 started by Onur Karaman. --- > move all partition and replica state transition rules into a

[jira] [Created] (KAFKA-5258) move all partition and replica state transition rules into a map

Onur Karaman created KAFKA-5258: --- Summary: move all partition and replica state transition rules into a map Key: KAFKA-5258 URL: https://issues.apache.org/jira/browse/KAFKA-5258 Project: Kafka

[jira] [Comment Edited] (KAFKA-5175) Transient failure: ControllerIntegrationTest.testPreferredReplicaLeaderElection

[ https://issues.apache.org/jira/browse/KAFKA-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011851#comment-16011851 ] Onur Karaman edited comment on KAFKA-5175 at 5/16/17 7:01 AM: -- Cool. I can

[jira] [Commented] (KAFKA-5175) Transient failure: ControllerIntegrationTest.testPreferredReplicaLeaderElection

[ https://issues.apache.org/jira/browse/KAFKA-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011851#comment-16011851 ] Onur Karaman commented on KAFKA-5175: - Cool. I can steadily reproduce this by inserting a long sleep

[jira] [Commented] (KAFKA-5175) Transient failure: ControllerIntegrationTest.testPreferredReplicaLeaderElection

[ https://issues.apache.org/jira/browse/KAFKA-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011500#comment-16011500 ] Onur Karaman commented on KAFKA-5175: - Thanks [~ijuma]. I've been staring at this and couldn't figure

[jira] [Commented] (KAFKA-3356) Remove ConsumerOffsetChecker, deprecated in 0.9, in 0.11

[ https://issues.apache.org/jira/browse/KAFKA-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16010823#comment-16010823 ] Onur Karaman commented on KAFKA-3356: - I agree with [~jeffwidman]. > Remove ConsumerOffsetChec

[jira] [Updated] (KAFKA-5180) Transient failure: ControllerIntegrationTest.testControllerMoveIncrementsControllerEpoch

[ https://issues.apache.org/jira/browse/KAFKA-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5180: Status: Patch Available (was: In Progress) > Transient fail

[jira] [Work started] (KAFKA-5180) Transient failure: ControllerIntegrationTest.testControllerMoveIncrementsControllerEpoch

[ https://issues.apache.org/jira/browse/KAFKA-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-5180 started by Onur Karaman. --- > Transient fail

[jira] [Resolved] (KAFKA-5120) Several controller metrics block if controller lock is held by another thread

[ https://issues.apache.org/jira/browse/KAFKA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman resolved KAFKA-5120. - Resolution: Fixed KAFKA-5028 has been checked in so this should no longer be an issue. > Seve

[jira] [Resolved] (KAFKA-3107) Error when trying to shut down auto balancing scheduler of controller

[ https://issues.apache.org/jira/browse/KAFKA-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman resolved KAFKA-3107. - Resolution: Fixed This problem should no longer exist after KAFKA-5028. > Error when try

Re: [DISCUSS] KIP-143: Controller Health Metrics

> could > >> be slower than we expect. > >> 6. EventAckTime: The time waiting for all the corresponding responses. > >> 7. EventHandlingTotalTime: sum of 2-6 > >> > >> Note that all the metrics are from the event and cluster wide state > >> transition point o

Re: [DISCUSS] KIP-143: Controller Health Metrics

I had a similar comment to Becket but accidentally posted it on the vote thread last Friday. From that thread: "I noticed that both the ControllerState metric and the *RateAndTimeMs metrics only cover a subset of the controller event types. Was this intentional?" I think it makes most sense to

[jira] [Updated] (KAFKA-5197) add a tool analyzing zookeeper client performance across its various apis

[ https://issues.apache.org/jira/browse/KAFKA-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5197: Status: Patch Available (was: In Progress) > add a tool analyzing zookeeper client performa

[jira] [Work started] (KAFKA-5197) add a tool analyzing zookeeper client performance across its various apis

[ https://issues.apache.org/jira/browse/KAFKA-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-5197 started by Onur Karaman. --- > add a tool analyzing zookeeper client performance across its various a

[jira] [Created] (KAFKA-5197) add a tool analyzing zookeeper client performance across its various apis

Onur Karaman created KAFKA-5197: --- Summary: add a tool analyzing zookeeper client performance across its various apis Key: KAFKA-5197 URL: https://issues.apache.org/jira/browse/KAFKA-5197 Project: Kafka

[jira] [Commented] (KAFKA-5099) Replica Deletion Regression from KIP-101

[ https://issues.apache.org/jira/browse/KAFKA-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000261#comment-16000261 ] Onur Karaman commented on KAFKA-5099: - By the way, I reran the file descriptor experiment against both

Re: [VOTE] KIP-143: Controller Health Metrics

I noticed that both the ControllerState metric and the *RateAndTimeMs metrics only cover a subset of the controller event types. Was this intentional? On Fri, May 5, 2017 at 6:03 PM, Gwen Shapira wrote: > +1 > > On Thu, May 4, 2017 at 7:34 PM, Ismael Juma

[jira] [Commented] (KAFKA-5099) Replica Deletion Regression from KIP-101

[ https://issues.apache.org/jira/browse/KAFKA-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999200#comment-15999200 ] Onur Karaman commented on KAFKA-5099: - Hi [~junrao]. Thanks for figuring it out. I gave your solution

Re: [DISCUSS] KIP-153 : Include only client traffic in BytesOutPerSec metric

Looks good. Thanks! On Fri, May 5, 2017 at 4:44 PM, Roger Hoover wrote: > Very helpful. Thank you, Jun. > > On Fri, May 5, 2017 at 4:42 PM, Guozhang Wang wrote: > > > Jun, > > > > Thanks for the KIP, LGTM. > > > > Guozhang > > > > On Fri, May 5,

[jira] [Assigned] (KAFKA-5180) Transient failure: ControllerIntegrationTest.testControllerMoveIncrementsControllerEpoch

[ https://issues.apache.org/jira/browse/KAFKA-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman reassigned KAFKA-5180: --- Assignee: Onur Karaman > Transient fail

[jira] [Assigned] (KAFKA-5175) Transient failure: ControllerIntegrationTest.testPreferredReplicaLeaderElection

[ https://issues.apache.org/jira/browse/KAFKA-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman reassigned KAFKA-5175: --- Assignee: Onur Karaman > Transient fail

Re: [DISCUSS] KIP-143: Controller Health Metrics

Regarding the ControllerState and the potential for overlap, I think it depends on our definition of controller state. While KAFKA-5028 allows only a single ControllerEvent to be processed at a time, it still allows interleavings for long-lasting actions like partition reassignment and topic

[jira] [Updated] (KAFKA-5107) remove preferred replica election state from ControllerContext

[ https://issues.apache.org/jira/browse/KAFKA-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5107: Status: Patch Available (was: In Progress) > remove preferred replica election state f

[jira] [Work started] (KAFKA-5107) remove preferred replica election state from ControllerContext

[ https://issues.apache.org/jira/browse/KAFKA-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-5107 started by Onur Karaman. --- > remove preferred replica election state from ControllerCont

[jira] [Commented] (KAFKA-5028) convert kafka controller to a single-threaded event queue model

[ https://issues.apache.org/jira/browse/KAFKA-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15987101#comment-15987101 ] Onur Karaman commented on KAFKA-5028: - Shortly after check-in, I noticed a bug: the patch has

[jira] [Commented] (KAFKA-5120) Several controller metrics block if controller lock is held by another thread

[ https://issues.apache.org/jira/browse/KAFKA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982118#comment-15982118 ] Onur Karaman commented on KAFKA-5120: - This will be fixed in KAFKA-5028. It chooses the latter

[jira] [Updated] (KAFKA-5107) remove preferred replica election state from ControllerContext

[ https://issues.apache.org/jira/browse/KAFKA-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5107: Summary: remove preferred replica election state from ControllerContext (was: investigate removing

[jira] [Created] (KAFKA-5107) investigate removing preferred replica leader election state from ControllerContext

Onur Karaman created KAFKA-5107: --- Summary: investigate removing preferred replica leader election state from ControllerContext Key: KAFKA-5107 URL: https://issues.apache.org/jira/browse/KAFKA-5107

[jira] [Commented] (KAFKA-5099) Replica Deletion Regression from KIP-101

[ https://issues.apache.org/jira/browse/KAFKA-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977902#comment-15977902 ] Onur Karaman commented on KAFKA-5099: - My initial guess is that the new epoch checkpoint file isn't

[jira] [Created] (KAFKA-5099) Replica Deletion Regression from KIP-101

Onur Karaman created KAFKA-5099: --- Summary: Replica Deletion Regression from KIP-101 Key: KAFKA-5099 URL: https://issues.apache.org/jira/browse/KAFKA-5099 Project: Kafka Issue Type: Bug

[jira] [Created] (KAFKA-5083) always leave the last surviving member of the ISR in ZK

Onur Karaman created KAFKA-5083: --- Summary: always leave the last surviving member of the ISR in ZK Key: KAFKA-5083 URL: https://issues.apache.org/jira/browse/KAFKA-5083 Project: Kafka Issue

[jira] [Updated] (KAFKA-5069) add controller integration tests

[ https://issues.apache.org/jira/browse/KAFKA-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5069: Status: Patch Available (was: In Progress) > add controller integration te

[jira] [Updated] (KAFKA-5028) convert kafka controller to a single-threaded event queue model

[ https://issues.apache.org/jira/browse/KAFKA-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5028: Status: Patch Available (was: In Progress) > convert kafka controller to a single-threaded ev

[jira] [Work started] (KAFKA-5069) add controller integration tests

[ https://issues.apache.org/jira/browse/KAFKA-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-5069 started by Onur Karaman. --- > add controller integration te

[jira] [Created] (KAFKA-5069) add controller integration tests

Onur Karaman created KAFKA-5069: --- Summary: add controller integration tests Key: KAFKA-5069 URL: https://issues.apache.org/jira/browse/KAFKA-5069 Project: Kafka Issue Type: Sub-task

Re: [VOTE] KIP-134: Delay initial consumer group rebalance

Hi Damian. Can you copy the point Becket made earlier that you say isn't addressed? On Thu, Apr 6, 2017 at 2:51 AM, Damian Guy wrote: > Thanks all, the Vote is now closed and the KIP has been accepted with 9 +1s > > 3 binding:: > Guozhang, > Jason, > Ismael > > 6

[jira] [Work started] (KAFKA-5028) convert kafka controller to a single-threaded event queue model

[ https://issues.apache.org/jira/browse/KAFKA-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-5028 started by Onur Karaman. --- > convert kafka controller to a single-threaded event queue mo

[jira] [Updated] (KAFKA-5028) convert kafka controller to a single-threaded event queue model

[ https://issues.apache.org/jira/browse/KAFKA-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-5028: Summary: convert kafka controller to a single-threaded event queue model (was: Convert Kafka

[jira] [Created] (KAFKA-5028) Convert Kafka Controller to a single-threaded event queue model

Onur Karaman created KAFKA-5028: --- Summary: Convert Kafka Controller to a single-threaded event queue model Key: KAFKA-5028 URL: https://issues.apache.org/jira/browse/KAFKA-5028 Project: Kafka

[jira] [Created] (KAFKA-5027) Kafka Controller Redesign

Onur Karaman created KAFKA-5027: --- Summary: Kafka Controller Redesign Key: KAFKA-5027 URL: https://issues.apache.org/jira/browse/KAFKA-5027 Project: Kafka Issue Type: Improvement

Re: [VOTE] KIP-134: Delay initial consumer group rebalance

earer and probably safer than letting the > group members to guess the state of a group. Can you elaborate a little bit > on your idea? > > Thanks, > > Jiangjie (Becket) Qin > > On Mon, Apr 3, 2017 at 8:16 AM, Onur Karaman <onurkaraman.apa...@gmail.com > > >

Re: [VOTE] KIP-134: Delay initial consumer group rebalance

Hi Damian. After reading the discussion thread again, it still doesn't seem like the thread discussed the option I mentioned earlier. >From what I had understood from the broker-side vs. client-side config debate was that the client-side config from the discussion would cause a wire format

Re: [VOTE] KIP-134: Delay initial consumer group rebalance

It seems like there generally has been the assumption that the broker needs to know about this delay either from its own config or provided over the wire from clients. Is this actually true? One alternative I don't think was mentioned was to make this delay concept be completely client-side.

[jira] [Updated] (KAFKA-4959) remove controller concurrent access to non-threadsafe NetworkClient, Selector, and SSLEngine

[ https://issues.apache.org/jira/browse/KAFKA-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Onur Karaman updated KAFKA-4959: Status: Patch Available (was: In Progress) > remove controller concurrent access to non-threads

[jira] [Work started] (KAFKA-4959) remove controller concurrent access to non-threadsafe NetworkClient, Selector, and SSLEngine

[ https://issues.apache.org/jira/browse/KAFKA-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-4959 started by Onur Karaman. --- > remove controller concurrent access to non-threadsafe NetworkClient, > Se

[jira] [Created] (KAFKA-4959) remove controller concurrent access to non-threadsafe NetworkClient, Selector, and SSLEngine

Onur Karaman created KAFKA-4959: --- Summary: remove controller concurrent access to non-threadsafe NetworkClient, Selector, and SSLEngine Key: KAFKA-4959 URL: https://issues.apache.org/jira/browse/KAFKA-4959

[jira] [Commented] (KAFKA-4900) Brokers stuck in controller re-election loop after failing to register metrics

[ https://issues.apache.org/jira/browse/KAFKA-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15943568#comment-15943568 ] Onur Karaman commented on KAFKA-4900: - [~nickt] Do you think it makes sense for me to open a new

[jira] [Commented] (KAFKA-4900) Brokers stuck in controller re-election loop after failing to register metrics

[ https://issues.apache.org/jira/browse/KAFKA-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941296#comment-15941296 ] Onur Karaman commented on KAFKA-4900: - I haven't figured out some of the small details but I think I

[jira] [Commented] (KAFKA-4900) Brokers stuck in controller re-election loop after failing to register metrics

[ https://issues.apache.org/jira/browse/KAFKA-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15929447#comment-15929447 ] Onur Karaman commented on KAFKA-4900: - Okay yeah with bad znode data, I could see how the controller

[jira] [Commented] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927298#comment-15927298 ] Onur Karaman commented on KAFKA-4893: - Also [~vahid] while I agree reducing the limit is by far

[jira] [Commented] (KAFKA-4900) Brokers stuck in controller re-election loop after failing to register metrics

[ https://issues.apache.org/jira/browse/KAFKA-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927200#comment-15927200 ] Onur Karaman commented on KAFKA-4900: - I hadn't yet investigated why some of the fetchers hadn't

[jira] [Comment Edited] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927155#comment-15927155 ] Onur Karaman edited comment on KAFKA-4893 at 3/15/17 11:23 PM: --- [~ijuma] I

[jira] [Commented] (KAFKA-4893) async topic deletion conflicts with max topic length

[ https://issues.apache.org/jira/browse/KAFKA-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927155#comment-15927155 ] Onur Karaman commented on KAFKA-4893: - [~ijuma] I had thought about the additional fsync

  1   2   3   4   5   >