Re: [VOTE] KIP-62: Allow consumer to send heartbeats from a background thread

On Mon, Jun 20, 2016 at 9:32 PM, Jay Kreps wrote: > Also, checked exceptions? Really Ewen??? :-) > Haha, yeah. I thought checked exceptions were universally disliked. People who favour static typing tend to prefer Disjunction/Either and the rest tend to prefer unchecked

Re: [VOTE] KIP-4 Create Topics Schema

hu, Jun 16, 2016 at 6:05 PM, Harsha <ka...@harsha.io> wrote: > >> > >> > +1 (binding) > >> > Thanks, > >> > Harsha > >> > > >> > On Thu, Jun 16, 2016, at 04:15 PM, Guozhang Wang wrote: > >> > > +1. > >&

Re: [VOTE] KIP-62: Allow consumer to send heartbeats from a background thread

If we do that, shouldn't `max.poll.records` remain with the current default of `Integer.MAX_VALUE`? On Sat, Jun 18, 2016 at 5:18 PM, Jay Kreps wrote: > +1 > > One small but important thing I think we should consider changing: I think > we should consider setting the default

Re: Initiating a new KIP

Hi Arvind. What is your wiki id? Ismael On Sat, Jun 18, 2016 at 7:53 PM, Arvind Kandhare wrote: > Hi, > I would like to initiate a new KIP. It looks like I do not have access to > the wiki. Can I get the access please? > > Thanks and regards, > Arvind >

Re: FYI - Apache ZooKeeper Backup, a Treatise

Hi Flavio, Comments below. On Sat, Jun 18, 2016 at 4:50 PM, Flavio Junqueira wrote: > For acls, you can simply re-run the acl command to re-introduce them, > unless you assume that no record of acls is maintained once they are > introduced. If that's the case, then another way

Re: [DISCUSS] KAFKA-3761: Controller has RunningAsBroker instead of RunningAsController state

+1 from me. Ismael On Thu, Jun 23, 2016 at 11:57 PM, Roger Hoover wrote: > Hi all, > > Does anyone have an issue with removing the broker state called > "RunningAsController"? > > The reasons to remove it are: > 1. It's currently broken. The purpose of the JIRA >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

was already expanded > > from a new method to a complete rewrite of the authorizer. Is the > > current location really bad enough to expand the scope into larger > > refactoring of Kafka? > > > > Gwen > > > > On Wed, Apr 20, 2016 at 10:43 PM, Ismael Juma <ism.

Re: ScalaStyle Feedback

backporting PRs to 0.9.0 regularly, but maybe this will change in the near future as the important bugs are tackled. Ismael On Fri, Jan 8, 2016 at 5:33 PM, Ismael Juma <ism...@juma.me.uk> wrote: > Hey Grant, > > As you know I think this is definitely valuable. My take: > > 1

Re: ScalaStyle Feedback

Hey Grant, As you know I think this is definitely valuable. My take: 1. The choice of rules is really important and it's a good plan to be conservative initially (as you suggested) 2. We should only use errors, not warnings 3. To make the previous one feasible, the rules we enable must not have

Re: Automated PR builds

I filed https://issues.apache.org/jira/browse/INFRA-11065 about an hour ago. Ismael On Mon, Jan 11, 2016 at 3:08 PM, Grant Henke wrote: > It looks like the automated builds have stopped triggering. Any ideas what > could be the cause? > > Thanks, > Grant > -- > Grant Henke

Re: Kafka build fails

Hi Vahid, It looks like the Gradle version you installed is 1.5. Kafka requires at least 2.0. Ismael On Wed, Jan 13, 2016 at 11:45 PM, Vahid S Hashemian < vahidhashem...@us.ibm.com> wrote: > Hi, > > I am trying to build Kafka on a fresh Ubuntu VM using the following > commands and gradle is

Re: [VOTE] KIP-41: Consumer Max Records

+1 (non-binding) On Thu, Jan 14, 2016 at 6:26 AM, Neha Narkhede wrote: > +1 (binding) > > > > > > > On Wed, Jan 13, 2016 at 9:10 PM -0800, "Joel Koshy" > wrote: > > > > > > > > > > > +1 > > On Wed, Jan 13, 2016 at 3:18 PM, Jason Gustafson wrote: > > >

Re: [DISCUSS] KIP-36 - Rack aware replica assignment

On Thu, Jan 14, 2016 at 1:24 AM, Allen Wang wrote: > Updated KIP regarding how broker JSON version will be handled and new > procedure of upgrade. Thanks Allen. In the following text, I think we should replace 0.9.0 with 0.9.0.0: "Due to a bug introduced in 0.9.0 in

Re: [VOTE] KIP-65 Expose timestamps to Connect

+1 (binding), provided that we make the usage of `Long/null` versus `long/-1` consistent. Ismael On Sat, Jun 25, 2016 at 12:42 AM, Gwen Shapira wrote: > +1 > > On Fri, Jun 24, 2016 at 10:59 AM, Shikhar Bhushan > wrote: > > Since there isn't much to

Re: [DISCUSS] KIP-65 Expose timestamps to Connect

Hi Shikhar, Thanks for the KIP. One question: SinkRecord takes a `long` timestamp, but then exposes it via a method that returns `Long`. Is this correct? And if so, can you please explain the reasoning? Ismael On Thu, Jun 23, 2016 at 8:06 PM, Shikhar Bhushan wrote: >

Re: [DISCUSS] KIP-65 Expose timestamps to Connect

; up there :-) > > Thanks, > > Shikhar > > On Fri, Jun 24, 2016 at 3:52 PM Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Shikhar, > > > > Thanks for the KIP. One question: > > > > SinkRecord takes a `long` timestamp, but then exposes

Re: KAFKA-3002 issue in 0.9.0.0

Hi Roman, See the following email from Jun: http://search-hadoop.com/m/uyzND1nOVTTEB7pS=Kafka+0+9+0+1+plan 0.9.0.1 will be out soon and it will include KAFKA-3002. Ismael On Mon, Feb 8, 2016 at 6:26 AM, Roman Hoc wrote: > Hello, > I got no answer from you side about

Re: [POLL] Make next Kafka Release 0.10.0.0 instead of 0.9.1.0

Hi Becket, Thanks for starting the discussion. Given the significance of the changes, I think 0.10.0.0 is appropriate. However, I think we have to be careful about the fact that we will be releasing two major releases within a short period of time. This means that 0.10.0.0 may be out before

Re: Kafka 0.9.0.1 plan

> Thanks, > Allen > > > On Fri, Feb 5, 2016 at 1:19 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Becket, > > > > On Fri, Feb 5, 2016 at 9:15 PM, Becket Qin <becket@gmail.com> wrote: > > > > > I am taking KAFKA-3177 off the

Re: Kafka 0.9.0.1 plan

Hi Becket, On Fri, Feb 5, 2016 at 9:15 PM, Becket Qin wrote: > I am taking KAFKA-3177 off the list because the correct fix might involve > some refactoring of exception hierarchy in new consumer. That may take some > time and 0.9.0.1 probably does not need to block on it.

Re: [POLL] Make next Kafka Release 0.10.0.0 instead of 0.9.1.0

Hi Becket, Good points. Some comments inline. On Tue, Feb 9, 2016 at 8:45 PM, Becket Qin wrote: > Good point on the upgrade path. The release plan says that 0.10.0.0 is > targeted in Q2, 2016. If that is accurate, there are 6-7 months between > 0.9.0.0 and 0.10.0.0, i.e.

Re: New Consumer Poll bug?

Hi Damian, KAFKA-2978, which would cause consumption to stop would happen after a consumer group rebalance. Was this the case for you? It would be great if you could upgrade the client to 0.9.0.1 RC1 in order to check if the problem still happens. There were other bugs fixed in the 0.9.0 branch

Re: New Consumer Poll bug?

this case it wasn’t a rebalance as I was using consumer.assign(..) > > I’ll give it a try with the 0.9.0.1 client to see if i can reproduce. > > I’ve tried the 0.9.0.1 client with consumer groups and it seemed to work > > fine even when constantly rebalancing. Thanks for the tip! &g

Re: [DISCUSS] KIP-47 - Add timestamp-based log deletion policy

Hi Bill, Thanks for the proposal, it makes sense. A minor comment: `log.retention.mintimestamp` should maybe be called `log.retention.min.timestamp` to be consistent with other properties. Also, it would be good to update the KIP to mention the LogAppendTime point. Ismael On Sat, Feb 13, 2016

Code Contribution wiki tweaks

Hi all, I did a couple of tweaks to the "Contributing Code Changes"[1] wiki page: 1. I noted that PR submitters should add a comment to the PR after they've addressed comments from reviewers (no notification is sent otherwise). I added this because I noticed that some people weren't doing that

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

eriodically. > > > > > > > > > > > > > > > > I understand most of the login logic would be simple but it > is > > > good > > > > > > that > > > > > > > we > > > > > > > > can expose the

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

Hi Pierre and Jason, A comment below. On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson wrote: > Hi Pierre, > > Thanks for your persistence on this issue. I've gone back and forth on this > a few times. The current API can definitely be annoying in some cases, but > breaking

Re: [DISCUSS] KIP-44 - Allow Kafka to have a customized security protocol

Tao, Thanks for the KIP. As others are saying, it would be helpful to have more details on why a new SASL mechanism was rejected in this KIP. An example of how using a new SASL mechanism would be more complex when compared to using a customised security protocol (for example) would help. Ismael

Re: [DISCUSS] KIP-42: Add Producer and Consumer Interceptors

Hi Anna and Neha, I think it makes a lot of sense to try and keep the interface lean and to add more methods later when/if there is a need. What is the current thinking with regards to compatibility when/if we add new methods? A few options come to mind: 1. Change the interface to an abstract

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Hi Rajini, Thanks for the KIP. As stated in the KIP, it does not address "Support for multiple SASL mechanisms within a broker". Maybe we should also mention this in the "Rejected Alternatives" section with the reasoning. I think it's particularly relevant to understand if it's not being proposed

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

On Mon, Feb 1, 2016 at 7:04 PM, Gwen Shapira wrote: > Looking at "existing solutions", it looks like Zookeeper allows plugging in > any SASL mechanism, but the server will only support one mechanism at a > time. > This was the original proposal from Rajini as that is enough

Re: [VOTE] KIP-42 -- Add Producer and Consumer Interceptors.

+1 (non-binding) Ismael On Mon, Feb 1, 2016 at 10:23 PM, Jay Kreps wrote: > +1 > > -Jay > > On Mon, Feb 1, 2016 at 12:00 PM, Anna Povzner wrote: > > > Hi All, > > > > I am opening the voting thread for KIP-42: Add Producer and Consumer > > Interceptors. >

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Hi Gwen, On Mon, Feb 1, 2016 at 6:06 AM, Gwen Shapira wrote: > Could we support separate SASL mechanisms via separate ports? > This option was also discussed in the KIP and there are some advantages as you say. However, there are some drawbacks as well. This was the main

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Hi Gwen, A few comments below. On Mon, Feb 1, 2016 at 4:30 PM, Gwen Shapira wrote: > Thanks for clarifying, Ismael and Rajini. And I'm sorry for reopenning a > point that was clearly discussed already. Your input is definitely welcome. :) There was an initial discussion in

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

Hi Becket, On Wed, Jan 27, 2016 at 10:51 PM, Becket Qin wrote: > 2. For seek(), pause(), resume(), it depends on how easily user can use > them. > If we take current interface, and user have a list of partitions to > pause(), what they can do is something like: >

Re: [DISCUSS] Deprecating the old Scala producers for the next release

Hi Flavio, On Tue, Feb 23, 2016 at 10:46 AM, Flavio Junqueira wrote: > It does make sense, thanks for the clarification. If we deprecate the > producer first, does it mean that the following release won't have a scala > producer but will have a scala consumer? Actually I should

Re: [DISCUSS] Deprecating the old Scala producers for the next release

Hi Jay, Comments inline. On Tue, Feb 23, 2016 at 10:38 AM, Jay Kreps wrote: > Would it make more sense to be able to announce both new clients stable and > deprecate both the scala clients at the same time (irrespective of whether > that is next release or one after)? I

Re: [DISCUSS] Deprecating the old Scala producers for the next release

Hi Andrew, Thanks for your input. On Tue, Feb 23, 2016 at 11:16 AM, Andrew Schofield < andrew_schofield_j...@outlook.com> wrote: > From my point of view, it seems very odd to deprecate the Scala producer > but not the consumer. So, I would vote to deprecate them both in 0.10. > I explained in

Re: [DISCUSS] Deprecating the old Scala producers for the next release

23, 2016 at 3:25 AM, Joel Koshy <jjkosh...@gmail.com> wrote: > > > > > +1 > > > > > > Thanks for bringing it up > > > > > > On Mon, Feb 22, 2016 at 9:36 AM, Ismael Juma <ism...@juma.me.uk> > wrote: > > > > > >

Re: [DISCUSS] Deprecating the old Scala producers for the next release

Hi Flavio, On Tue, Feb 23, 2016 at 9:23 AM, Flavio Junqueira wrote: > Ismael, I'm curious about why you want to deprecate one and not the other. > You say that it is premature to deprecate the old scala consumers and I'm > wondering about the reasoning behind it. > The new

Re: [VOTE] Make next Kafka release 0.10.0.0 instead of 0.9.1.0

I also changed the "Fix version" for a number of recent JIRAs from 0.10.0.0 to 0.9.1.0. The reason is that once we rename the JIRA versions (as per KAFKA-3276), they will all automatically become 0.10.0.0 (without causing a storm of notifications). Ismael On Tue, Feb 23, 2016 at 10:26

Re: [VOTE] Make next Kafka release 0.10.0.0 instead of 0.9.1.0

Thank you Becket. I have: * Updated KIP wiki page so that all KIPs with a target of 0.9.1.0 now target 0.10.0.0 * Filed https://issues.apache.org/jira/browse/KAFKA-3275 to track tasks that still need to be done. The next step would be to update JIRA versions as per

[DISCUSS] Deprecating the old Scala producers for the next release

Hi all, The new Java producer was introduced in 0.8.2.0 (released in February 2015). It has become the default implementation for various tools since 0.9.0.0 (released in October 2015) and it is the only implementation with support for the security features introduced in 0.9.0.0. Given this, I

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

Thanks Pierre. Including the dev mailing list. A few comments: 1. It's worth mentioning that the KafkaConsumer has the @InterfaceStability.Unstable annotation. 2. It would be good to show the existing signatures of the methods being changed before we show the changed signatures. 3. The proposed

Re: [VOTE] KIP-36 - Rack aware replica assignment

+1 (non-binding) On Tue, Jan 19, 2016 at 6:12 AM, Guozhang Wang wrote: > +1 (binding) > > On Mon, Jan 18, 2016 at 2:43 PM, Onur Karaman > > wrote: > > > +1 (non-binding) > > > > On Mon, Jan 18, 2016 at 2:32 PM, Jun Rao

Re: 0.9.0.1 RC1

+1 (non-binding). Verified source and binary artifacts, ran ./gradlew testAll with JDK 7u80, quick start on source artifact and Scala 2.11 binary artifact. Ismael On Fri, Feb 12, 2016 at 2:55 AM, Jun Rao wrote: > This is the first candidate for release of Apache Kafka

Re: [POLL] Make next Kafka Release 0.10.0.0 instead of 0.9.1.0

we reference the version number. Ismael On Wed, Feb 10, 2016 at 1:33 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Becket, > > Good points. Some comments inline. > > On Tue, Feb 9, 2016 at 8:45 PM, Becket Qin <becket@gmail.com> wrote: > >> Good point o

Re: [VOTE] Make next Kafka release 0.10.0.0 instead of 0.9.1.0

+1 (non-binding) Ismael On Fri, Feb 19, 2016 at 7:00 PM, Becket Qin wrote: > Hi All, > > We would like to start this voting thread on making next Kafka release > 0.10.0.0 instead of 0.9.1.0. > > The next Kafka release will have several significant important new >

Re: [DISCUSS] KIP-47 - Add timestamp-based log deletion policy

Hi Bill, It would be good to add some information on the CreateTime versus LogAppendTime issue. Aside from that, it seems like you could start the VOTE thread. That sometimes triggers additional discussion and that is fine. Ismael On Fri, Feb 19, 2016 at 10:57 PM, Bill Warshaw

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hi Gwen, On Mon, Mar 14, 2016 at 4:37 PM, Gwen Shapira <g...@confluent.io> wrote: > On Mon, Mar 14, 2016 at 7:05 AM, Ismael Juma <ism...@juma.me.uk> wrote:> > >>1. Every time a protocol version changes, for any request/response, > >>broker ve

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hi Ashish, Comments inline. On Mon, Mar 14, 2016 at 6:15 PM, Ashish Singh wrote: > I think ApiVersion aims to identify protocol version changes, more than > release change, > > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/api/ApiVersion.scala#L30 >

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 8:45 PM, Gwen Shapira wrote: > > > I don't see how it helps. If the client is communicating with a broker > that > > does not support KIP-35, that broker will simply close the connection. If > > the broker supports KIP-35, then it will provide the broker

Re: [DISCUSS] KIP-35 - Retrieve protocol version

On Mon, Mar 14, 2016 at 10:35 PM, Ashish Singh wrote: > > Also, I think it's a bit odd to say a `single null topic with size -1`. > Do > > we mean an array of topics with size -1 and no elements? That would imply > > introducing a NULLABLE_ARRAY type (we currently have

Re: [DISCUSS] KIP-35 - Retrieve protocol version

We introduced a way to bump the API version in between releases as part of the KIP-31/KIP-32 by the way. Extending that could maybe work. Take a look at the ApiVersion class and its documentation. Ismael On 11 Mar 2016 19:06, "Gwen Shapira" wrote: > Magnus, > > If we go with

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Hi Ashish, A few comments below. On Fri, Mar 11, 2016 at 9:59 PM, Ashish Singh wrote: > Sounds like we are mostly in agreement. Following are the key points. > >1. Every time a protocol version changes, for any request/response, >broker version, ApiVersion, will be

Re: KIP-4 Wiki Update

On Wed, Mar 30, 2016 at 6:21 PM, Gwen Shapira wrote: > Ismael, can you detail how the Optional approach would work in the wire > protocol? It sounds good, but I'm unclear on what this would look like on > the wire. > In the wire protocol, we would still use a size of -1 like

Re: KIP-4 Wiki Update

gt; On Wed, Mar 30, 2016 at 10:53 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > On Wed, Mar 30, 2016 at 6:21 PM, Gwen Shapira <g...@confluent.io> wrote: > > > > > Ismael, can you detail how the Optional approach would work in the wire > > > protoco

Re: KIP-4 Wiki Update

My concern is that this approach is error-prone and a bit magical. It is possible to do that in the wire protocol while using a safer approach in the code if people prefer this option (by using a type like `Optional` in Java). Ismael On Wed, Mar 30, 2016 at 5:33 PM, Jason Gustafson

Re: [DISCUSS] KIP-35 - Retrieve protocol version

Yeah, we should use nullable arrays (which have been introduced in KIP-4-Metadata) instead of empty list to indicate all versions. Ismael On 5 Apr 2016 18:01, "Ewen Cheslack-Postava" wrote: > Also, just a thought but is empty list the sentinel we really want to > indicate we

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Hi Jay, On Wed, Apr 6, 2016 at 3:48 AM, Jay Kreps wrote: > Given that we're breaking compatibility anyway should we: > We are not breaking source compatibility since the new method has a default implementation. I take it that you mean binary compatibility? > 1. Remove the

Re: [VOTE] KIP-4 Metadata Schema (Round 2)

+1 (non-binding) On Fri, Apr 8, 2016 at 10:41 PM, Grant Henke wrote: > I would like to re-initiate the voting process for the "KIP-4 Metadata > Schema changes". This is not a vote for all of KIP-4, but specifically for > the metadata changes. I have included the exact

Re: [VOTE] KIP-4 Metadata Schema (Round 2)

+1 (non-binding) Ismael On Tue, Apr 12, 2016 at 2:19 AM, Jun Rao wrote: > Grant, > > Thanks for the updated version. +1 from me. > > Jun > > On Mon, Apr 11, 2016 at 10:42 AM, Grant Henke wrote: > > > Based on the discussion in the previous vote thread >

Re: [DISCUSS] KIP-35 - Retrieve protocol version

I alone to > match 0.9.0.x or we would need to support two different wire protocols for > GSSAPI. Neither sounds ideal. > > On Tue, Apr 12, 2016 at 9:18 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Jun, > > > > I understand the point about the SA

Re: [DISCUSS] KIP-35 - Retrieve protocol version

; evolve over time > > > > without breaking existing clients. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We started KIP-35 with supporting a client to know if a version is

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Hi Jun, Comments inline. On Mon, Apr 11, 2016 at 1:57 AM, Jun Rao wrote: > Yes, that should be fine right? Since the new api key will start with a 0 > byte, it actually guarantees that it's different from 0x60 (1st byte in the > old protocol) even if we change the request

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Hi Jun, A couple of points below. On Sat, Apr 9, 2016 at 12:19 AM, Jun Rao wrote: > 5. Your main request is how can a client know that the broker is now > supporting new SASL mechanisms. One way to support that is to adjust KIP-43 > slightly. We can model the

Re: [DISCUSS] KIP-52 - Add Connector Control APIs

resume should be idempotent and actually represent > > updating a resource that gets written to Kafka (although I must admit I > > don't know if the use of 202/Accepted should affect this at all), the > > restart endpoints seem a bit different as they are one-off immediate >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Jay > > On Tue, Apr 5, 2016 at 11:46 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Jay, > > > > On Wed, Apr 6, 2016 at 3:48 AM, Jay Kreps <j...@confluent.io> wrote: > > > > > Given that we're breaking compatibility anyway should we

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

It is small, but breaks binary compatibility. Ismael On Wed, Apr 6, 2016 at 5:20 PM, Grant Henke <ghe...@cloudera.com> wrote: > KIP-50 as defined is very small. I don't see any harm in putting it in as > is and then tackling the follow up work. > > > On Wed, Apr 6, 2016 at

Re: [VOTE] KIP-52: Kafka Connect Control APIs

+1 (non-binding) Ismael On Thu, Apr 7, 2016 at 1:25 AM, Jason Gustafson wrote: > Minor note: I've changed the restart API to be blocking as discussed in the > other thread. > > -Jason > > On Tue, Apr 5, 2016 at 9:02 PM, Guozhang Wang wrote: > > > +1 > >

Re: [VOTE] KIP-45: Standardize KafkaConsumer API to use Collection

+1 (non-binding) Ismael On Tue, Mar 15, 2016 at 9:18 PM, Jason Gustafson wrote: > I'd like to open the vote for KIP-45. We've discussed several alternatives > on the mailing list and in the KIP call, but this vote is only on the > documented KIP: >

Re: Build failed in Jenkins: kafka-trunk-jdk7 #1134

In case you were wondering, these failures were due to the fact that the Gradle build configs in Apache Jenkins got messed up somehow: https://issues.apache.org/jira/browse/INFRA-11514 Andrew Bayer has fixed the issue. Ismael On Mon, Mar 21, 2016 at 8:45 PM, Apache Jenkins Server <

Re: [VOTE] KIP-51 - List Connectors REST API

+1 (non-binding) Ismael On Tue, Mar 22, 2016 at 10:46 PM, Ewen Cheslack-Postava wrote: > Since it's pretty minimal, we'd like to squeeze it into 0.10 if possible, > and VOTE threads take 3 days, it was suggested it might make sense to just > kick off voting on this KIP

Re: Jenkins job for 0.10.0

Thanks Gwen! A quick heads up, the job was slightly changed to match the branch name: https://builds.apache.org/job/kafka-0.10.0-jdk7/ Ismael On Tue, Mar 22, 2016 at 5:43 PM, Gwen Shapira wrote: > Hi Team Kafka, > > Just a quick update - I've created a Jenkins job to test

Re: [VOTE] Deprecating the old Scala producers for 0.10.0.0

t;e...@confluent.io> wrote: > +1 > > On Mon, Mar 7, 2016 at 10:16 AM, Joel Koshy <jjkosh...@gmail.com> wrote: > > > +1 > > > > On Thu, Mar 3, 2016 at 2:36 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > > > Hi all, > > > > > >

[VOTE] Deprecating the old Scala producers for 0.10.0.0

Hi all, The new Java producer was introduced in 0.8.2.0 (released in February 2015). It has become the default implementation for various tools since 0.9.0.0 (released in October 2015) and it is the only implementation with support for the security features introduced in 0.9.0.0. Given this, I

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

l On Tue, Mar 1, 2016 at 3:11 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Rajini, > > One question below. > > On Tue, Mar 1, 2016 at 2:47 AM, Rajini Sivaram < > rajinisiva...@googlemail.com> wrote: > >>1. With GSSAPI, the first context establis

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Hi Rajini, One question below. On Tue, Mar 1, 2016 at 2:47 AM, Rajini Sivaram wrote: >1. With GSSAPI, the first context establishment packet starts with the >byte 0x60 (tag for APPLICATION-0) followed by a variable-length encoded >size, followed by

Re: [jira] [Created] (KAFKA-3325) Out of date instructions in quickstart guide

Thanks Duncan, would you like to submit a pull request to update the docs? I suggest we remove port from the example as it's redundant if we set listeners. Ismael On 3 Mar 2016 11:09, "Duncan Sands (JIRA)" wrote: > Duncan Sands created KAFKA-3325: >

Re: [VOTE] Release plan - Kafka 0.10.0

+1 (non-binding) Ismael On Mon, Mar 7, 2016 at 7:27 PM, Neha Narkhede wrote: > +1 (binding) > > On Mon, Mar 7, 2016 at 11:26 AM, Gwen Shapira wrote: > > > Hi Joe, > > > > The branch cutting means that new features will go into trunk, bug > > fixes will go

Re: [VOTE] KIP-43: Kafka SASL enhancements

+1 (non-binding) On Thu, Mar 3, 2016 at 10:37 AM, Rajini Sivaram < rajinisiva...@googlemail.com> wrote: > I would like to start the voting process for *KIP-43: Kafka SASL > enhancements*. This KIP extends the SASL implementation in Kafka to support > new SASL mechanisms to enable Kafka to be

Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism

I agree that it would be good to have more time to review and discuss KIP-48. Ismael On Tue, Mar 8, 2016 at 12:55 AM, Gwen Shapira wrote: > Hi Team, > > Since KIP-48 depends on KIP-43, which is already a bit of a risk for > the next release - any chance we can delay

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

Coming back to this, see below. On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson wrote: > > 1. For subscribe() and assign(), change the parameter type to collection as > planned in the KIP. This is at least source-compatible, so as long as users > compile against the updated

Re: [DISCUSS] KIP-43: Kafka SASL enhancements

Hi Rajini, Thanks for clarifying. Comments inline. On Tue, Mar 1, 2016 at 2:21 PM, Rajini Sivaram wrote: > > Since we want to support arbitrary custom mechanisms, it feels better to > use mechanism names rather than Strings. IDs would require ensuring that >

Re: [Discuss] Remove producer configs deprecated in 0.9

Thanks Gwen, I was going to say the exact same thing. :) Ismael On Wed, Mar 9, 2016 at 12:26 AM, Gwen Shapira wrote: > We are planning on supporting direct 0.8.2 to 0.10 upgrades (and are > adding tests to that effect). So we expect that quite a few users will > never see

Re: KIP-4 Wiki Update

being intuitive, it seems less > error-prone > > in the long term, though it might be a little annoying for clients > > maintaining backwards compatibility. > > > > -Jason > > > > On Thu, Mar 31, 2016 at 1:24 PM, Ismael Juma <ism...@juma.me.uk> wrote: >

Re: [RELEASE UPDATE] Postponing the next release candidates and canceling current vote

> > > > KIP-52 would be nice to get in as well. It's a small feature, but > really > > > helpful for Connect users. A patch for the first half is already > > available, > > > though it may need adjustment depending on the discussion. > > > > &

Re: [VOTE] KIP-4 Metadata Schema

Hi Jun, A couple of comments inline. On Sun, Apr 3, 2016 at 5:55 PM, Jun Rao wrote: > 1. It seems a bit weird to return just a list of internal topics w/o the > corresponding metadata. It also seems a bit weird to return the internal > topics even if the client doesn't ask

Re: KIP-4 Wiki Update

include java specific stuff in the wire protocol. > > Thanks, > > Jun > > On Sun, Apr 3, 2016 at 12:36 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Grant, > > > > One question that occurred to me is whether we want to take the chance to &

Re: KIP-4 Wiki Update

I haven't had a chance to look at the KIP in detail, but a quick comment below. On Wed, Mar 30, 2016 at 4:49 PM, Dana Powers wrote: > > MetadataRequest v1: long-term / conceptually, I think a "null" topic list > aligns better with fetching all topics. Empty list aligns

Re: KIP-4 Wiki Update

Hi Grant, I had a second look at the proposed changes to Metadata Request and Response and it seems to me that having a `controller_id` field would be more efficient for non-trivial cases than having a `is_controller` field for each broker (which would be false for all but 1 case). Similar, but

Re: [DISCUSS] KIP-35 - Retrieve protocol version

ively by configuration)." Ismael On Fri, Apr 1, 2016 at 9:22 AM, Ismael Juma <ism...@juma.me.uk> wrote: > A couple of questions: > > 1. The KIP says "Specific version may be deprecated through protocol > documentation but must still be supported (although it is fair to return an

Re: [DISCUSS] KIP-35 - Retrieve protocol version

A couple of questions: 1. The KIP says "Specific version may be deprecated through protocol documentation but must still be supported (although it is fair to return an error code if the specific API supports it).". It may be worth expanding this a little more. For example, what does it mean to

Re: KIP-4 Wiki Update

ill seems like it would be a win for when > it > >> matters most (when the number of topics is large). > >> > > > > Thats an interesting idea. I can try making this change to see what it > > would look like. > > > > Thanks, > > Grant > &

Re: [VOTE] KIP-4 Metadata Schema

+1 (non-binding) On Fri, Apr 1, 2016 at 6:38 PM, Ashish Singh wrote: > +1 (non-binding) > > On Fri, Apr 1, 2016 at 10:16 AM, Gwen Shapira wrote: > > > +1 > > > > On Fri, Apr 1, 2016 at 10:12 AM, Jason Gustafson > > wrote: > > > > >

Re: [DISCUSS] KIP-52 - Add Connector Control APIs

Hi Jason, Do I understand correctly that these requests are idempotent? If so, why are they POSTs instead of PUTs? Ismael On Thu, Mar 31, 2016 at 5:31 PM, Jason Gustafson wrote: > Hi All, I've written a short KIP to add control APIs to Kafka Connect to > make

Re: [VOTE] KIP-43: Kafka SASL enhancements

Since the KIP changed since my last vote, +1 (non-binding). Rajini, do you want to wrap up the vote? It seems like we have 3 binding +1s (Harsha, Gwen and Jun). Ismael On Tue, Mar 29, 2016 at 3:22 PM, Jun Rao wrote: > Rajini, > > Thanks for the update. +1 on the proposal. >

Re: [DISCUSS] KIP-50 - Enhance Authorizer interface to be aware of supported Principal Types

Hi Ashish, A few comments on the proposal: 1. In Kafka, we don't use use getter convention generally. However, the other methods in the `Authorizer` interface do follow the getter convention, which is unfortunate. So, I am OK with the name you suggested (getSupportedPrincipalTypes instead of

1000+ GitHub pull requests closed

Hi all, In July 2015, the community voted to start using GitHub pull requests for contributions. Right now, just over 1000 pull requests have been closed[1], which is a nice milestone. This is only possible due to the great work by both committers and contributors. Nice one. :) Having said that,

Re: How will KIP-35 and KIP-43 play together?

e from its custom protocol > > format > > into the Kafka protocol and make it use the proper Kafka protocol > framing. > > > > (For SSL this is isnt needed since TLS has its own _standardised_ > > hand-shake format and existing SSL implementations take care of

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