Re: [VOTE] KIP-19 Add a request timeout to NetworkClient

+1 non-binding. Thanks for all the work on this Jiangjie! Aditya -- see discussion of partitionsFor() API, which needs to also use one of those timeouts, and is a fetch rather than a send since it's just getting metadata. -Ewen On Tue, Jun 2, 2015 at 4:44 PM, Aditya Auradkar < aaurad...@linkedin

Re: Review Request 34789: Patch for KAFKA-2168

This naming threw me off when I was looking at callers, at first I thought offsetResetNeeded() was checking the value and offsetResetNeeded(TopicPartition) was setting a flag that the TopicPartition needed offsets reset. Maybe rename these to isOffsetResetNeeded to clarify, leaving needOffsetReset()

Re: Review Request 35023: Patch for KAFKA-2246

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/35023/#review86478 --- Ship it! Ship It! - Ewen Cheslack-Postava On June 3, 2015, 8:33

Review Request 35076: Patch for KAFKA-2248

-review.py b5a2e950110d44d20d21e3d72be1783ceb49627d scala.gradle cabb59c2a6289bc3a2673ddfa3842addf9a5bb44 topics.json ff011ed381e781b9a177036001d44dca3eac586f Diff: https://reviews.apache.org/r/35076/diff/ Testing --- Thanks, Ewen Cheslack-Postava

Re: Review Request 34789: Patch for KAFKA-2168

> On June 3, 2015, 6:44 a.m., Ewen Cheslack-Postava wrote: > > clients/src/main/java/org/apache/kafka/clients/consumer/KafkaConsumer.java, > > line 1091 > > <https://reviews.apache.org/r/34789/diff/3/?file=976965#file976965line1091> > > > > Since poll

Re: Review Request 34789: Patch for KAFKA-2168

e from using it anywhere else -- this is really the only place it should be needed. LGTM once rebased against trunk, only had a few minor comments. The naming of the DelayedResult classes could be changed, but I think none of the options we have are entirely clear so I wouldn't worry about that

Re: Review Request 34789: Patch for KAFKA-2168

> On June 3, 2015, 6:44 a.m., Ewen Cheslack-Postava wrote: > > clients/src/main/java/org/apache/kafka/clients/consumer/KafkaConsumer.java, > > line 1091 > > <https://reviews.apache.org/r/34789/diff/3/?file=976965#file976965line1091> > > > > Since poll

Re: Review Request 33196: Patch for KAFKA-2123

uozhang, just FYI I was going to wait on finishing this patch for KAFKA-2168 since I think it'll actually simplify this one quite a bit. - Ewen --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33196/#review85920 --

Re: Kafka Connect key.converter and value.converter properties for Avro encoding

You won't be accepting/returning SpecificRecords directly when working with Connect's API. Connect intentionally uses an interface that is different from Kafka serializers because we deal with structured data that the connectors need to be able to understand. We define a generic runtime representat

Re: [DISCUSS] KAFKA-4345: Run decktape test for each pull request

Yeah, I'm all for getting these to run more frequently and on lighter weight infrastructure. (By the way, I also saw the use of docker; I'd really like to get a "native" docker cluster type into ducktape at some point so all you have to do is bake the image and then spawn containers on demand.) A

Re: [DISCUSS] KAFKA-4345: Run decktape test for each pull request

On Mon, Nov 7, 2016 at 10:30 AM Raghav Kumar Gautam wrote: > Hi Ewen, > > Thanks for the feedback. Answers are inlined. > > On Sun, Nov 6, 2016 at 8:46 PM, Ewen Cheslack-Postava > wrote: > > > Yeah, I'm all for getting these to run more frequently and on lighte

Re: Kafka Connect key.converter and value.converter properties for Avro encoding

ly seeing this from converting a null value in Kafka. If the value in Kafka is null, there's no way to know what the intended schema was, so it has to be left blank. However, since null is used in compacted topics for deletion, it is important to actually translate null values in Connect to be t

Re: Use Android App as a “Producing client” for Kafka?

Artur, It is possible to do this, but the second approach you mentioned is much more common. Normally people don't want to expose their Kafka cluster publicly, so having an intermediary can be a good way to, e.g., add a layer where you can easily filter out bad traffic. You may be able to use some

Re: [DISCUSS] KIP-89: Allow sink connectors to decouple flush and offset commit

I don't have much to say here since I reviewed a draft of this already. But I did want to point out that although it expands the API for Connectors (which I think we should be conservative about), it has the really nice impact that it allows connectors that really care about high throughput to avoi

Re: [VOTE] KIP-89: Allow sink connectors to decouple flush and offset commit

+1 (binding) -Ewen On Wed, Nov 9, 2016 at 2:16 PM, Shikhar Bhushan wrote: > Hi, > > I would like to initiate a vote on KIP-89 > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 89%3A+Allow+sink+connectors+to+decouple+flush+and+offset+commit > > Best, > > Shikhar > -- Thanks, Ewen

Re: Upgrading from kafka-0.8.1.1 to kafka-0.9.0.1

The errors you're seeing sound like an issue where you updated the artifact but didn't recompile against the newer Scala version. Did you recompile or just replace the Kafka jar with a newer one? -Ewen On Wed, Nov 9, 2016 at 4:31 PM, Divyajothi Baskaran wrote: > Hi, > For the past 6 months,I am

Re: Reg: DefaultParititioner in Kafka

When a key is available, you generally include it because you want all messages with the same key to always end up in the same partition. This allows all messages with the same key to be processed by the same consumer (e.g. allowing you to aggregate all data for a single user if you key on user ID)

Re: KafkaProducer.java topics() call?

Generally the producer knows the set of topics it wants to produce to because it is fixed by the application (even if dynamic, there isn't commonly much use in exposing this functionality). You're right it could be implemented, but the use cases seem limited. If you have a good use case, please fo

Re: [DISCUSS] KIP-93: Improve invalid timestamp handling in Kafka Streams

I think this looks reasonable, but just a more general note on compatibility -- I think it's worth trying to clarify what types of compatibility we're trying to achieve. Guozhang's 1 & 2 give an important breakdown (compile vs runtime compatibility). For the type of change described here, I think i

Re: [VOTE] KIP-93: Improve invalid timestamp handling in Kafka Streams

+1 (binding). Also, see my notes in discussion thread around future compatibility discussions for breaking plugin interface changes like this. -Ewen On Tue, Nov 29, 2016 at 3:54 PM, Guozhang Wang wrote: > +1. > > On Tue, Nov 29, 2016 at 11:05 AM, Bill Bejeck wrote: > > > +1 (non-binding) > >

Re: [VOTE] KIP-94: Session Windows

+1 binding -Ewen On Tue, Dec 6, 2016 at 3:21 PM, Bill Bejeck wrote: > +1 > > On Tue, Dec 6, 2016 at 4:55 PM, Guozhang Wang wrote: > > > +1 (binding) > > > > On Tue, Dec 6, 2016 at 9:07 AM, Matthias J. Sax > > wrote: > > > > > +1 > > > > > > On 12/6/16 7:40 AM, Eno Thereska wrote: > > > > +1 (

Re: [DISCUSS] KIP-97: Improved Kafka Client RPC Compatibility Policy

On Sat, Dec 10, 2016 at 5:23 PM, Sven Ludwig wrote: > Hi, > > as a user I find this concept interesting, but not important enough. I > just want to share my personal thoughts, potentially leaning myself > somewhat out of the window, that came to my mind during reading: > > - I think it is of utmo

Re: [VOTE] KIP-87 - Add Compaction Tombstone Flag

It seemed like this was addressed in the migration section, wasn't it? The V2 vs V3 requests and the fact that the broker will downgrade the message format (losing zero copy) if you issues a V2 request to a broker using V3 format handles compatibility, does it not? The existing consumers won't see

Re: [VOTE]: KIP-97: The client compatibility KIP

+1 (binding) -Ewen On Sat, Dec 10, 2016 at 2:41 PM, Jay Kreps wrote: > +1 (binding) > > -Jay > > On Wed, Dec 7, 2016 at 9:17 AM, Colin McCabe wrote: > > > Hi all, > > > > I heard that the VOTE and DISCUSS threads for the KIP-97 discussion > > appeared to be in the same email thread for some pe

Re: [DISCUSS] KIP-95: Incremental Batch Processing for Kafka Streams

A few thoughts: > introduce a Streams metadata topic (single partitioned and log compacted; one for each application-ID) I would consider whether the single partition is a strict requirement. A single partition increases the likelihood of outages. This is something I'd like to see changed in Conn

Re: [VOTE] KIP-88: OffsetFetch Protocol Update

+1 (binding) The AdminClient piece will probably need follow up, but given that it's defined in the context of incomplete KIP-4 design, I'm kind of assuming it's still up for further discussion once we hit the implementation of that class (where I think a wholistic view of the API is needed). Vah

Re: [DISCUSS] KIP-66 Kafka Connect Transformers for messages

e/display/KAFKA/ > Connect+Transforms+-+Proposed+Design > > I'd welcome your feedback and comments. > > Thanks, > > Shikhar > > On Tue, Aug 2, 2016 at 7:21 PM Ewen Cheslack-Postava > wrote: > > On Thu, Jul 28, 2016 at 11:58 PM, Shikhar Bhushan > wrote: > >

Re: [VOTE] KIP-100 - Relax Type constraints in Kafka Streams API

+1 (binding) My only concern was around compatibility. It seems like the one case it is incompatible would be, at worst, an extremely unusual edge case (and I *think* can be restricted further to "not source compatible for anyone extending the affected classes / interfaces and override affected me

Re: [VOTE] KIP-87 - Add Compaction Tombstone Flag

throw new IllegalArgumentException( > > String.format("Tombstone must be true if null > value")); > > } > > this.topic = topic; > > this.partition = partition; > > this.tombstone = tombstone; > >

Re: [DISCUSS] KIP-102 - Add close with timeout for consumers

Rajini, Thanks for this KIP, I'd definitely like to see this. Connect has had a long-standing TODO around stopping sink tasks where we can't properly manage the rebalance process (which involves stopping consumers) because we lack a timeout here. Not a huge problem in practice, but would be nice t

Re: [DISCUSS] KIP-66 Kafka Connect Transformers for messages

ng, both options > end > > up > > > looking pretty similar (in terms of how transformations are implemented > > and > > > the runtime initializes and uses them) and I'm starting to lean towards > > not > > > adding a new interface into the mix. >

Re: [DISCUSS] KIP-66 Kafka Connect Transformers for messages

g implemented by > > > > connectors in divergent ways: RegexRouter, Insert, Replace, > > > HoistToStruct, > > > > ExtractFromStruct > > > > > > > > On Wed, Dec 14, 2016 at 6:00 PM Gwen Shapira > > wrote: > > > > >

Re: Please add my wiki username contributor permission list

I've granted you permissions, you should now be able to edit the main KIP page and add a new KIP. -Ewen On Fri, Dec 30, 2016 at 2:58 PM, Aarti Gupta wrote: > Hey devs, > > My jira username is aartigupta > and my wiki username happens to be aartiguptaa > (not sure how that happened) > > I alrea

Re: New question / request on kafka consumer

This sounds related to https://issues.apache.org/jira/browse/KAFKA-1894 Currently the consumer won't timeout when it cannot contact the brokers. -Ewen On Wed, Dec 14, 2016 at 5:21 AM, Costache, Vlad < vlad.costa...@metrosystems.net> wrote: > Hello, > > > > We are trying to make a consumer for ka

Re: Multiple Consumer Group In Single Topic

Rico, Every consumer group will see all messages for the topics they are subscribed to. If you want to filter these messages by consumer group, you'd need to perform that filtering yourself after the messages are returned by the consumer. To do so, you'd need to include enough information in the m

Re: [VOTE] KIP-100 - Relax Type constraints in Kafka Streams API

This passes with 4 binding and 7 total +1 votes. Xavier, I've marked the JIRA for 0.10.2.0, which I assume we'll be able to make, and moved it as WIP into the adopted KIPs section. -Ewen On Mon, Dec 19, 2016 at 2:33 PM, Guozhang Wang wrote: > +1. > > On Sat, Dec 17, 2016 at 3:27 AM, Ismael Jum

Re: [VOTE] KIP-90 Remove zkClient dependency from Streams

Looks like this passes with 4 binding and 8 total +1 votes. Hojjat, I've moved it into the adopted KIPs table and marked the JIRA for 0.10.2.0 if we can get it into that release. -Ewen On Wed, Dec 21, 2016 at 12:55 AM, Matthias J. Sax wrote: > +1 > > > On 12/21/16 12:45 AM, Edoardo Comar wrote

0.10.2.0 release planning

Hey folks, We're quickly approaching our next time-based release. If you missed any of the updates on the new time-based releases we'll be following, see https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan for an explanation. I've started to organize the 0.10.2.0 release, sc

Re: [VOTE] KIP-99: Add Global Tables to Kafka Streams

+1 -Ewen On Tue, Jan 3, 2017 at 11:16 AM, Gwen Shapira wrote: > +1 > > I'm glad this super-common use-case will become more performant now. > > On Mon, Dec 12, 2016 at 3:45 AM, Damian Guy wrote: > > Hi all, > > > > I'd like to start the vote for KIP-99: > > https://cwiki.apache.org/confluence/

Re: [DISCUSS] KIP 88: OffsetFetch Protocol Update

Vahid, This looks reasonable to me and fits well with the changes made for metadata requests. -Ewen On Tue, Jan 3, 2017 at 12:12 PM, Vahid S Hashemian < vahidhashem...@us.ibm.com> wrote: > One more try to ask for feedback on this KIP (that had to go through some > more changes after approval):

Re: [DISCUSS] KIP-107: Add purgeDataBefore() API in AdminClient

Dong, Looks like that's an internal link, https://cwiki.apache.org/confluence/display/KAFKA/KIP-107%3A+Add+purgeDataBefore%28%29+API+in+AdminClient is the right one. I have a question about one of the rejected alternatives: > Using committed offset instead of an extra API to trigger data purge o

Re: [DISCUSS] KIP-107: Add purgeDataBefore() API in AdminClient

thing new besides a) time-based b) size-based or c) consumed-based? > > > > #1 is a configuration mess, since there are multiple possible strategies. > > #2 is problematic without a definition of "liveliness" or special > handling > > for console consumer? an

Re: [DISCUSS] KIP-107: Add purgeDataBefore() API in AdminClient

to have a Consumer-based implementation since that seems like a very intuitive, natural way to use the protocol. I think optimizing for the expected use case would be a good idea. -Ewen > > Thanks, > Dong > > On Tue, Jan 3, 2017 at 3:56 PM, Ewen Cheslack-Postava > wrote: >

[DISCUSS] KIP-128: Add ByteArrayConverter for Kafka Connect

Hi all, I've added a pretty trivial KIP for adding a pass-through Converter for Kafka Connect, similar to ByteArraySerializer/Deserializer. https://cwiki.apache.org/confluence/display/KAFKA/KIP-128%3A+Add+ByteArrayConverter+for+Kafka+Connect This wasn't added with the framework originally becaus

Re: [DISCUSS] KIP-128: Add ByteArrayConverter for Kafka Connect

o.a.k.common? > > Guozhang > > On Sat, Feb 25, 2017 at 2:25 PM, Ewen Cheslack-Postava > wrote: > > > Hi all, > > > > I've added a pretty trivial KIP for adding a pass-through Converter for > > Kafka Connect, similar to ByteArraySerializer/D

Re: [DISCUSS] KIP-128: Add ByteArrayConverter for Kafka Connect

; "use the corresponding serializer internally and just add in the extra > conversion > steps for the data API" sounds good to me. > > Guozhang > > > On Mon, Feb 27, 2017 at 8:24 AM, Ewen Cheslack-Postava > wrote: > > > It's a different interface that&#

Re: [VOTE] KIP-119: Drop Support for Scala 2.10 in Kafka 0.11

+1 (binding) -Ewen On Wed, Mar 1, 2017 at 4:56 AM, Jozef.koval wrote: > +1 (non-binding) > > Jozef > > P.S. I volunteer to help with this KIP. > > > Sent from [ProtonMail](https://protonmail.ch), encrypted email based in > Switzerland. > > > > Original Message > Subject: Re: [

Re: [DISCUSS] KIP-128: Add ByteArrayConverter for Kafka Connect

is useful. > > Gwen > > > > On Sat, Feb 25, 2017 at 2:25 PM, Ewen Cheslack-Postava > wrote: > > Hi all, > > > > I've added a pretty trivial KIP for adding a pass-through Converter for > > Kafka Connect, similar to ByteArraySerializer/Deserializ

0.10.2.0 Release Retrospective

Hi all, I think it'd be useful to review & refine our release process, especially in light of the new time based releases. I've created a page under the release plan for 0.10.2.0 and added some of my notes: https://cwiki.apache.org/confluence/display/KAFKA/0.10.2.0+Retrospective If others could

[VOTE] KIP-128: Add ByteArrayConverter for Kafka Connect

Hi all, I'd like to kick off voting for KIP-128: Add ByteArrayConverter for Kafka Connect: https://cwiki.apache.org/confluence/display/KAFKA/KIP-128%3A+Add+ByteArrayConverter+for+Kafka+Connect There was a small amount of discussion, see the original thread here: https://lists.apache.org/thread.h

Re: [VOTE] KIP-128: Add ByteArrayConverter for Kafka Connect

Hah, I forgot to do it in the original email, but I suppose I should make it explicit: +1 (binding) -Ewen On Mon, Mar 6, 2017 at 9:26 PM, Gwen Shapira wrote: > +1 (binding) > > On Mon, Mar 6, 2017 at 7:53 PM, Ewen Cheslack-Postava > wrote: > > > Hi all, > > > >

Re: [VOTE] KIP-128: Add ByteArrayConverter for Kafka Connect

://goog_969573159/)github.com/dongjinleekr ( > http://github.com/dongjinleekr) > > twitter: www.twitter.com/dongjinleekr (http://www.twitter.com/ > dongjinleekr) > > > > > > > > > > > > > > > On Mar 8, 2017 at 3:45 PM, mailto:r...@confl

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

I have the same initial response as Ismael re: broker vs consumer settings. The global setting seems questionable. Could we maybe summarize what the impact of making this a client config would be? Protocol bump is obvious, but is there any other significant issue? For the protocol bump in particul

Re: [VOTE] KIP-120: Cleanup Kafka Streams builder API

+1 (binding) -Ewen On Thu, Mar 30, 2017 at 4:03 PM, Guozhang Wang wrote: > +1. > > > On Thu, Mar 30, 2017 at 1:18 AM, Damian Guy wrote: > > > Thanks Matthias. > > > > +1 > > > > On Thu, 23 Mar 2017 at 22:40 Matthias J. Sax > > wrote: > > > > > Hi, > > > > > > I would like to start the VOTE on

Re: [DISCUSS] KIP-123: Allow per stream/table timestamp extractor

I agree there's a potential issue that Eno raises, but probably it's not worth worrying about trying to enforce it. It seems like we have the right default for long term and for most cases a custom timestamp extractor should only be needed for legacy data that isn't putting a timestamp in the recor

Re: [VOTE] KIP-123: Allow per stream/table timestamp extractor

+1 (binding) Left a few more comments in the DISCUSS thread, but nothing that would affect voting. Might also want to note somewhere in the KIP wiki that this interacts with KIP-120. Not critical, but it might help someone reading the KIPs for 0.11 figure out that they should actually be using the

Re: [DISCUSS] KIP-138: Change punctuate semantics

Arun, I've given you permission to edit the wiki. Let me know if you run into any issues. -Ewen On Fri, Apr 7, 2017 at 1:21 AM, Arun Mathew wrote: > Thanks Michal. I don’t have the access yet [arunmathew88]. Should I be > sending a separate mail for this? > > I thought one of the person follow

Re: Heads up: KAFKA-1697 - remove code related to ack>1 on the broker

Right, so this looks like it could create an issue similar to what's currently being discussed in https://issues.apache.org/jira/browse/KAFKA-1649 where users now get errors under conditions when they previously wouldn't. Old clients won't even know about the error code, so besides failing they won

Re: [kafka-clients] Re: Heads up: KAFKA-1697 - remove code related to ack>1 on the broker

ery single one of their producer requests start to fail > > and > > > they have a major production outage. k > > > > > > I do 100% agree that > 1 makes no sense and we *REALLY* need people to > > start > > > using 0,1,-1 but we need to-do

Re: [DISCUSS] KIPs

I think adding a section about deprecation would be helpful. A good fraction of the time I would expect the goal of a KIP is to fix or replace older functionality that needs continued support for compatibility, but should eventually be phased out. This helps Kafka devs understand how long they'll e

Re: [kafka-clients] Re: Heads up: KAFKA-1697 - remove code related to ack>1 on the broker

he need to add errors, but will also be less >> >>> clear to the client and its users. Maybe even add the error message >> >>> string to the protocol in addition to the error code? (since we are >> >>> bumping versions) >> >>> >>

Re: Review Request 27799: New consumer

4062> I'm confused what's going on here -- why Integer.MIN_VALUE? And how does this end up working with the rest of the code since this result node is used for consumerCoordinator and other code compares node IDs? core/src/main/scala/kafka/tools/ConsumerPerformance.scala <ht

Re: Cannot stop Kafka server if zookeeper is shutdown first

Looks like a bug to me -- the underlying ZK library wraps a lot of blocking method implementations with waitUntilConnected() calls without any timeouts. Ideally we could just add a version of ZkUtils.getController() with a timeout, but I don't see an easy way to accomplish that with ZkClient. Ther

Re: Review Request 30763: Patch for KAFKA-1865

looks good to me. clients/src/main/java/org/apache/kafka/clients/producer/internals/RecordAccumulator.java <https://reviews.apache.org/r/30763/#comment117336> This isn't properly reset in the case of InterruptionExceptions. This should be in a finally block. - Ewen Cheslack-P

Re: Kafka New(Java) Producer Connection reset by peer error and LB

Bhavesh, I'm unclear what the impact is here. The line numbers don't match up exactly with trunk or 0.8.2.0, but it looks like this exception is just caught and logged. As far as I can tell the producer would continue to function normally. Does this have any impact on the producer or is the concer

Re: Kafka New(Java) Producer Connection reset by peer error and LB

, it should close connection to "LB:port1" (In my > > opinion, this would be expected behavior). > > > > As you mentioned, producer behavior is normal and this error is harmless. > > If you consider this as a bug, please let me know and I will file j

Re: Review Request 31040: Patch for kafka-1952

urgatory to hold on to? I think the current code probably makes more sense, but I want to check since, given the CPU usage problem wasn't identified in the original patch it seems we previously thought the check was worth it. - Ewen Cheslack-Postava On Feb. 14, 2015,

Re: Review Request 29379: Patch for KAFKA-1788

> On Jan. 6, 2015, 6:43 p.m., Parth Brahmbhatt wrote: > > clients/src/main/java/org/apache/kafka/clients/producer/internals/RecordAccumulator.java, > > line 225 > > > > > > sender.completeBatch() is only called as par

Re: Review Request 29379: Patch for KAFKA-1788

870> Add final - Ewen Cheslack-Postava On Jan. 6, 2015, 6:44 p.m., Parth Brahmbhatt wrote: > > --- > This is an automatically generated e-mail. To reply, visit: >

Re: Review Request 31363: Patch for kafka-1984

- Ewen Cheslack-Postava On Feb. 24, 2015, 5:43 p.m., Jun Rao wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.

Review Request 31447: Patch for KAFKA-1881

: https://reviews.apache.org/r/31447/diff/ Testing --- Thanks, Ewen Cheslack-Postava

Re: Review Request 31447: Patch for KAFKA-1881

iews.apache.org/r/31447/#review74200 --- On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote: > > --- > This is an automatically generated e-mail. To reply

Re: Review Request 31447: Patch for KAFKA-1881

> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote: > > Ah, now I get what "dedupe buffer" refers to :) > > > > I never managed to reproduce the oom, but this looks like the right fix. > > Ewen Cheslack-Postava wrote: > This happened consistently f

Re: Review Request 31447: Patch for KAFKA-1881

> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote: > > Ah, now I get what "dedupe buffer" refers to :) > > > > I never managed to reproduce the oom, but this looks like the right fix. > > Ewen Cheslack-Postava wrote: > This happened consistently f

Re: Review Request 30763: KAFKA-1865: Producer Flush: Remove synchronization.

/MockProducer.java <https://reviews.apache.org/r/30763/#comment120749> synchronized no longer matches the regular non-Mock version. - Ewen Cheslack-Postava On Feb. 26, 2015, 1:16 a.m., Jay Kreps wrote: > > --- > This is a

Re: Review Request 31447: Patch for KAFKA-1881

> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote: > > Ah, now I get what "dedupe buffer" refers to :) > > > > I never managed to reproduce the oom, but this looks like the right fix. > > Ewen Cheslack-Postava wrote: > This happened consistently f

Re: Review Request 31510: Patch for kafka-1400

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31510/#review74411 --- Ship it! LGTM. Tested 50 times with no failures. - Ewen Cheslack

Review Request 31806: Patch for KAFKA-1501

a/unit/kafka/zk/ZooKeeperTestHarness.scala 67d9c4bab270c852dc05d47aaa4dd96b0f6039d4 Diff: https://reviews.apache.org/r/31806/diff/ Testing --- Thanks, Ewen Cheslack-Postava

Re: Review Request 31806: Patch for KAFKA-1501

KPathTest.scala 9897b2fa8f8261fe8ab6b62b45b9052adb07043f core/src/test/scala/unit/kafka/zk/ZooKeeperTestHarness.scala 67d9c4bab270c852dc05d47aaa4dd96b0f6039d4 Diff: https://reviews.apache.org/r/31806/diff/ Testing --- Thanks, Ewen Cheslack-Postava

Re: Review Request 31806: Patch for KAFKA-1501

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31806/#review75654 ------- On March 9, 2015, 6:41 p.m., Ewen Cheslack-Postava wrote: > > --

Re: adding replicas to existing topic partitions - KAFKA-1313

Geoff, First, if you haven't already, take a look at https://cwiki.apache.org/confluence/display/KAFKA/KIP-6+-+New+reassignment+partition+logic+for+rebalancing and the associated JIRA. My opinion is that we shouldn't do anything to the existing partitions -- it would probably violate the principl

Re: [jira] [Commented] (KAFKA-1646) Improve consumer read performance for Windows

I think the real problem is that the conditionals are spread across a bunch of different files. Seven special cases isn't necessarily unsustainable, but is difficult to manage now because they aren't isolated to one location. I think platform specific customizations are sustainable (as long as some

Re: [KIP-DISCUSSION] KIP-13 Quotas

Agreed that trying to shoehorn non-error codes into the error field is a bad idea. It makes it *way* too easy to write code that looks (and should be) correct but is actually incorrect. If necessary, I think it's much better to to spend a couple of extra bytes to encode that information separately

Re: [KIP-DISCUSSION] KIP-13 Quotas

se if(error.isFatal()) > >>> // non-retriable errors, etc: notify / terminate / other handling > >>> > >>> - > >>> > >>> Only when the clients really want to handle, for example > >>> FailDuetoThrottled >

Re: C++ Client Library -- libkafka-asio

You don't get edit permission by default, you need to get one of the admins to give you permission. @Daniel, I've added libkafka-asio. @svante I started to add csi-kafka, but couldn't find a license? On Sun, Mar 22, 2015 at 8:29 AM, svante karlsson wrote: > Cool, Looks nice. I was looking for

Re: Review Request 31806: Patch for KAFKA-1501

. - Ewen --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31806/#review76190 --- On March 9, 2015, 6:41 p.m., Ewen Cheslack-Postava wrote: > > --

Re: Review Request 31806: Patch for KAFKA-1501

/src/test/scala/unit/kafka/zk/ZKPathTest.scala 9897b2fa8f8261fe8ab6b62b45b9052adb07043f core/src/test/scala/unit/kafka/zk/ZooKeeperTestHarness.scala 67d9c4bab270c852dc05d47aaa4dd96b0f6039d4 Diff: https://reviews.apache.org/r/31806/diff/ Testing --- Thanks, Ewen Cheslack-Postava

Re: [VOTE] KIP-66: Single Message Transforms for Kafka Connect

+1 Gwen, re: bundling transformations, would it help at all to isolate them to a separate jar or is the concern purely about maintaining them as part of Kafka? -Ewen On Wed, Jan 4, 2017 at 1:31 PM, Sriram Subramanian wrote: > +1 > > On Wed, Jan 4, 2017 at 1:29 PM, Gwen Shapira wrote: > > > I

Re: 0.10.2.0 release planning

er "Open Issues", but not under "Planned KIP > > > > Content". Are those KIPs landing in this release or not? > > > > > > > > Thanks > > > > > > > > Tom > > > > > > > > On Mon, Jan 2, 2017 at 10:

Re: [VOTE] KIP-102 - Add close with timeout for consumers

+1 -Ewen On Thu, Jan 5, 2017 at 5:48 PM, Neha Narkhede wrote: > +1 (binding) > > On Thu, Jan 5, 2017 at 2:07 PM Rajini Sivaram > wrote: > > > Hi all, > > > > > > I would like to start the voting process for *KIP-102 - Add close with > > timeout for consumers*: > > > > > > > > https://cwiki.apa

Re: [VOTE] KIP-102 - Add close with timeout for consumers

For 0.10.2.0, this can absolutely make it in if we get the reviews done quickly enough. The cutoff for getting a new feature in would be the feature freeze on Jan 13 (when we generate the release branch and start having to cherry-pick commits, so we want to limit to stabilization and important bug

Re: [VOTE] KIP-88: OffsetFetch Protocol Update

+1 On Thu, Jan 5, 2017 at 1:30 PM, Ismael Juma wrote: > Thanks for the updates, +1 > > Ismael > > On Thu, Jan 5, 2017 at 6:14 PM, Vahid S Hashemian < > vahidhashem...@us.ibm.com > > wrote: > > > I'd like to start another round of voting on KIP-88 after recent changes > > to the KIP ( > > https:/

Re: Problem generating documentation locally

The core:siteDocsTar target should generate them. -Ewen On Fri, Jan 6, 2017 at 4:26 PM, Vahid S Hashemian wrote: > I'm trying to build the project documentation locally, but I can't seem to > be able to populate content for files in the 'docs/generated/' folder. > I've tried some of the doc-rel

Re: 0.10.2.0 release planning

which is currently scheduled for 0.10.2.0) uses create/delete > topics in the context of Streams. So, there is a user-visible impact. > 2. KIP-4 ACL hasn't been voted yet so that would have to happen too before > it could be included. > > Ismael > > On Thu, Jan 5, 2017 at 5:11 A

Re: [DISCUSS] KIP-109: Old Consumer Deprecation

I don't mean to derail this at all, but given Ismael's question I'm wondering what exactly we consider a message format change? Are we assuming that additions like a new compression format (i.e. semantic changes where previously undefined bits, but bits which existed) don't require a format version

Re: 0.10.2.0 release planning

, streams, connect, broker) to help you find which PRs you are comfortable reviewing quickly. -Ewen On Mon, Jan 9, 2017 at 5:16 PM, Ewen Cheslack-Postava wrote: > Hey folks, > > Here's a quick update and reminder that feature freeze is coming up on > Friday (don't worry, you&#

Re: [VOTE] KIP-109: Old Consumer Deprecation

Ismael, Is that regardless of whether it ends up being a major/minor version? i.e. given the way we've phrased (and I think started to follow through on) deprecations, if the next releases were 0.10.3.0 and then 0.11.0.0, the deprecation period would only be one release. That would be a tiny windo

Re: [DISCUSS] KIP-109: Old Consumer Deprecation

It might also be helpful for anyone who has done a bit of thinking around the migration story to dump their thoughts into the JIRA re: the plan. There are also questions I would have around what the exact requirements are. For example, if supporting auto commit is required, things get a lot hairier

Re: [DISCUSS] KIP-110: Add Codec for ZStandard Compression

FYI, there's an outstanding patch for getting some JMH benchmarking setup: https://github.com/apache/kafka/pull/1712 I haven't found time to review it (and don't really know JMH well anyway) but it might be worth getting that landed so we can use it for this as well. -Ewen On Wed, Jan 11, 2017 at

Re: 0.10.2.0 release planning

zing by the marked importance level would be greatly appreciated. Next release milestone will be code freeze on Jan 27th, at which point we'll start releasing and testing RCs. -Ewen On Mon, Jan 9, 2017 at 10:20 PM, Ewen Cheslack-Postava wrote: > As a quick follow up, for community members

<    1   2   3   4   5   6   7   8   9   10   >