Re: [VOTE] 1.1.0 RC1

Hello, We at Heroku have run 1.1.0 RC1 through our normal performance and regression test suite and have found performance to be comparable to 1.0.0. That said, we're however -1 (non-binding) since this release includes Zookeeper 3.4.11 which is

Re: [VOTE] 1.1.0 RC1

ook into this. > > > > Regards, > > Damian > > > > On Thu, 8 Mar 2018 at 18:27 Jeff Chao wrote: > > > > > Hello, > > > > > > We at Heroku have run 1.1.0 RC1 through our normal performance and > > > regression test suite and have

Re: Subject: [VOTE] 1.1.0 RC3

Hello again, Ran through our regression and performance suite. Everything checks out. Small note, release notes say ZK 3.4.11 is included (KAFKA-6390), but this was reverted in https://github.com/apache/kafka/pull/4678 as a MINOR commit. In any case, +1 (non-binding). Thanks, Jeff Heroku On Thu,

Re: [kafka-clients] Re: [VOTE] 1.1.0 RC4

Hello, +1 (non-binding). Ran through our regression and performance suite. Looks good, thanks. Jeff Chao Heroku On Tue, Mar 27, 2018 at 8:44 AM, Jason Gustafson wrote: > +1 Went through the quickstart, checked upgrade documentation. Thanks > Rajini! > > On Tue, Mar 27, 201

Re: Kafka KIP meeting on Apr. 9 at 9:00am PDT

Hi Jun, same for me. jeffc...@me.com Thanks, Jeff Chao On Thu, Apr 5, 2018 at 9:06 PM, Jun Rao wrote: > Hi, James, Jeff, > > Added you to the invitation. > > Jun > > On Thu, Apr 5, 2018 at 6:11 PM, Jeff Widman wrote: > > > Please add me as well: j...@jeffwidman

Re: [DISCUSS] KIP-253: Support in-order message delivery with partition expansion

top writing using the old scheme and start writing using the new scheme. That way, the consumer will be able to catch up in which it will start consuming using the new scheme afterwards. Thanks, Jeff Chao On Sat, Apr 14, 2018 at 6:44 AM, Dong Lin wrote: > Thanks for the notes by Jun and Ray. I

Re: [DISCUSS] KIP-253: Support in-order message delivery with partition expansion

ning scheme. Does this answer your question? > > Thanks, > Dong > > > On Sat, Apr 14, 2018 at 1:44 PM, Jeff Chao wrote: > > > Hi, I had a question from Monday's meeting. The current mechanism, as > Ray's > > notes points out, is to create a copy cons

Re: [VOTE] 1.0.0 RC4

+1 (non-binding). We ran our usual performance and regression suite and found no noticeable negative impacts. - Jeff Heroku On Tue, Oct 31, 2017 at 8:54 AM, Ted Yu wrote: > +1 (non-binding) > > Verified signatures. > Ran test suite. > > On Tue, Oct 31, 2017 at 8:53 AM, Manikumar > wrote: > > >

Re: [VOTE] 1.0.0 RC4

+1 (non-binding). We ran our usual performance and regression suite and found no noticeable negative impacts. - Jeff Heroku On Tue, Oct 31, 2017 at 8:54 AM, Ted Yu wrote: > +1 (non-binding) > > Verified signatures. > Ran test suite. > > On Tue, Oct 31, 2017 at 8:53 AM, Manikumar > wrote: > > >

Re: [VOTE] 1.0.0 RC4

+1 (non-binding). We ran our usual performance and regression suite and found no noticeable negative impacts. - Jeff Heroku On Tue, Oct 31, 2017 at 8:54 AM, Ted Yu wrote: > +1 (non-binding) > > Verified signatures. > Ran test suite. > > On Tue, Oct 31, 2017 at 8:53 AM, Manikumar > wrote: > >

Re: [VOTE] 0.11.0.0 RC2

Hi, Heroku has been doing additional performance testing on (1) log compaction and, separately (2) Go clients with older message format against 0.11-rc2 brokers with new message format. For log compaction, we've tested with messages using a single key, messages using unique keys, and messages wit

Aggressive log compaction ratio appears to have no negative effect on log-compacted topics

ee if anyone else has observed similar behavior. The motivation behind this is to see if we might consider changing the default from 0.5. This could help in preventing confusion around duplicate keys in low volume log-compacted topics use cases. Thanks, Jeff Chao Heroku Kafka

[jira] [Created] (KAFKA-5452) Aggressive log compaction ratio appears to have no negative effect on log-compacted topics

Jeff Chao created KAFKA-5452: Summary: Aggressive log compaction ratio appears to have no negative effect on log-compacted topics Key: KAFKA-5452 URL: https://issues.apache.org/jira/browse/KAFKA-5452

[jira] [Updated] (KAFKA-5452) Aggressive log compaction ratio appears to have no negative effect on log-compacted topics

[ https://issues.apache.org/jira/browse/KAFKA-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Chao updated KAFKA-5452: - Description: Some of our users are seeing unintuitive/unexpected behavior with log-compacted topics

[jira] [Created] (KAFKA-5463) Controller incorrectly logs rack information when new brokers are added

Jeff Chao created KAFKA-5463: Summary: Controller incorrectly logs rack information when new brokers are added Key: KAFKA-5463 URL: https://issues.apache.org/jira/browse/KAFKA-5463 Project: Kafka

[jira] [Resolved] (KAFKA-5452) Aggressive log compaction ratio appears to have no negative effect on log-compacted topics

[ https://issues.apache.org/jira/browse/KAFKA-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Chao resolved KAFKA-5452. -- Resolution: Resolved Following up after a long while. After talking offline with [~wushujames], the

[jira] [Created] (KAFKA-4725) Kafka broker fails due to OOM when producer exceeds throttling quota for extended periods of time

Jeff Chao created KAFKA-4725: Summary: Kafka broker fails due to OOM when producer exceeds throttling quota for extended periods of time Key: KAFKA-4725 URL: https://issues.apache.org/jira/browse/KAFKA-4725

[jira] [Commented] (KAFKA-4725) Kafka broker fails due to OOM when producer exceeds throttling quota for extended periods of time

[ https://issues.apache.org/jira/browse/KAFKA-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851898#comment-15851898 ] Jeff Chao commented on KAFKA-4725: -- Ok, we'll base it off trunk and open up a P