Re: [DISCUSS] Json libraries for Kafka

On Tue, Jul 14, 2015 at 10:46 PM, Joe Stein wrote: > Fasterxml/Jackson +1 to that. The scala databinds to case classes are gr8. > To be clear, case classes support would require the Scala module for Jackson and the Scala versions headache that goes with it (2.9 support is likely to be an issue,

Re: [DISCUSS] Json libraries for Kafka

Hi Jay, Comments inline. On Tue, Jul 14, 2015 at 11:04 PM, Jay Kreps wrote: > Is this going to become a dependency for core and then transitively for the > old clients? That's right. > The current json library is definitely not great, but it does > parse json and it's not used in any contex

Re: [DISCUSS] Using GitHub Pull Requests for contributions and code review

On Tue, Jul 14, 2015 at 6:15 PM, Jun Rao wrote: > I made a couple of changes to the new Jenkins job. Could you try again? > It's still not working, unfortunately. It may or may not be related to: https://blogs.apache.org/infra/entry/mirroring_to_github_issues For b, if we can't easily change t

Re: [DISCUSS] Json libraries for Kafka

On Mon, Jul 13, 2015 at 10:05 PM, Ismael Juma wrote: > * It's not thread-safe (so external locks are needed to use it in a > concurrent environment) > I realise now that I didn't make the impact of this very clear. The current code is acquiring a JVM-wide lock for the dur

Re: Review Request 36548: Patch for KAFKA-2336

> On July 16, 2015, 4:53 p.m., Edward Ribeiro wrote: > > core/src/main/scala/kafka/server/OffsetManager.scala, line 454 > > > > > > It looks like there's a mix of "if(" and "if (", with the latter being > > more use

Re: Review Request 36548: Patch for KAFKA-2336

> I will drop this issue for this specific patch. A standard can definitely > be addressed and made uniform in a new Jira. > > Ismael Juma wrote: > The Scala standard is to add a space after the `if`. > > Grant Henke wrote: > That's true: > http://docs.s

Re: Build failed in Jenkins: kafka-trunk-git-pr #8

Jun, what so you think about disabling emails to the list for this job? A comment is added to the pull request and I think that's good enough. People can configure their notification settings on GitHub to match their needs. Ismael On 17 Jul 2015 01:26, "Apache Jenkins Server" wrote: > See

Re: Build failed in Jenkins: kafka-trunk-git-pr #8

on step. Does that job work now? > > Thanks, > > Jun > > On Thu, Jul 16, 2015 at 5:41 PM, Ismael Juma wrote: > >> Jun, what so you think about disabling emails to the list for this job? A >> comment is added to the pull request and I think that's good enough

[VOTE] Drop support for Scala 2.9 for the next release

Hi all, I would like to start a vote on dropping support for Scala 2.9 for the next release. People seemed to be in favour of the idea in previous discussions: * http://search-hadoop.com/m/uyzND1uIW3k2fZVfU1 * http://search-hadoop.com/m/uyzND1KMLNK11Rmo72 Summary of why we should drop Scala 2.9:

Re: Review Request 36565: Patch for KAFKA-2345

/TopicAlreadyMarkedForDeletionException.scala (line 21) <https://reviews.apache.org/r/36565/#comment146030> Do we need this constructor? It's not used it and it's good to encourage people to include a message adding more detail, right? - Ismael Juma On July 17, 2015, 6:14 a.m., As

Re: Build failed in Jenkins: KafkaPreCommit #156

;> > >> [cshapi] KAFKA-2345; Attempt to delete a topic already marked for > deletion throws ZkNodeExistsException; patched by Ashish Singh; reviewed by > Sriharsha Chintalapani and Ismael Juma > >> > >> -- > >> Started

Re: Official Kafka Gitter Room?

Hi Grant, I have been considering proposing the same thing myself for similar reasons, but I also have some doubts. More comments inline. On Fri, Jul 17, 2015 at 7:28 PM, Grant Henke wrote: > I think it could be useful to have a place to chat that is associated with > the Kafka repo. Agreed.

Re: Review Request 36593: Patch for KAFKA-2347

ector". The rest looks good. - Ismael Juma On July 18, 2015, 5:02 a.m., Ashish Singh wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://revi

Re: Review Request 36593: Patch for KAFKA-2347

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36593/#review92190 --- Ship it! Ship It! - Ismael Juma On July 18, 2015, 10:14 p.m

Re: Official Kafka Gitter Room?

Hi Gwen, I like Slack and I think it's great for companies. However, there are a few things that make it less suitable for open-source projects, in my opinion. More below. On Sun, Jul 19, 2015 at 5:59 AM, Gwen Shapira wrote: > > Joining Slack requires an invitation. We can take invite-requests i

Re: Kafka Unit Test Failures on a Mac

Hello Grant, Thanks for figuring this out. I have also run into this issue when running the tests on OS X Yosemite. Ideally the tests would fail in a way that would make it clear what the issue is. That may be complicated, so we should at least document it as you suggest. I'll let you know if th

Re: [DISCUSS] JIRA issue required even for minor/hotfix pull requests?

On Mon, Jul 13, 2015 at 6:01 PM, Guozhang Wang wrote: > changing the statement in wiki that "you could create a PR with > [KAFKA-] or [MINOR], [HOTFIX], etc" > I went with this for now: The PR title should usually be of the form [KAFKA-] Title, where > KAFKA- is the relevant JIRA id

Re: [DISCUSS] JIRA issue required even for minor/hotfix pull requests?

On Mon, Jul 20, 2015 at 10:24 AM, Ismael Juma wrote: > I went with this for now: > Actually, I changed it to the following to match our existing commit prefix convention (instead of Spark's): > The PR title should usually be of the form KAFKA-; Title, where > KAFKA-xxx

Re: [VOTE] Drop support for Scala 2.9 for the next release

Thank you for voting. 72 hours have passed and the vote has passed with 5 binding +1s and 5 non-binding +1s. I filed https://issues.apache.org/jira/browse/KAFKA-2348 and created a pull request with the change. Best, Ismael On Fri, Jul 17, 2015 at 11:26 AM, Ismael Juma wrote: > Hi all, &g

Failing kafka-trunk-git-pr builds now fixed

Hi, All GitHub pull request builds were failing after we had a few successful ones. This should now be fixed and the same issue should not happen again. See the following for details: https://issues.apache.org/jira/browse/BUILDS-99 Best, Ismael

Re: Failing kafka-trunk-git-pr builds now fixed

On Mon, Jul 20, 2015 at 3:38 PM, Stevo Slavić wrote: > Can you please trigger the build for all of the currently opened pull > requests? > > E.g. my PR https://github.com/apache/kafka/pull/85 last automatically > added > comment is that the build has failed while it should have been success - > o

[VOTE] Switch to GitHub pull requests for new contributions

Hi all, I would like to start a vote on switching to GitHub pull requests for new contributions. To be precise, the vote is on whether we should: * Update the documentation to tell users to use pull requests instead of patches and Review Board (i.e. merge KAFKA-2321 and KAFKA-2349) * Use pull req

Re: Review Request 34641: Patch for KAFKA-2214

sible. core/src/main/scala/kafka/admin/ReassignPartitionsCommand.scala (line 80) <https://reviews.apache.org/r/34641/#comment146568> Nit: braces are not needed in case statements. - Ismael Juma On July 14, 2015, 10:13 a.m., Manikumar Reddy O wrote: > > -

Re: Review Request 35867: Patch for KAFKA-1901

867/#comment146572> Would it not be better to leave this value unset if we can't figure it out? clients/src/main/java/org/apache/kafka/common/utils/AppInfoParser.java (line 27) <https://reviews.apache.org/r/35867/#comment146573> Why isn't this "unknown" like `ver

Re: Review Request 36548: Patch for KAFKA-2336

's better to do `topicData.get(topic)` to avoid the `NoSuchElementException`. - Ismael Juma On July 16, 2015, 6:04 p.m., Grant Henke wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https

Re: [VOTE] Switch to GitHub pull requests for new contributions

On Tue, Jul 21, 2015 at 4:11 PM, Ashish Singh wrote: > +1 non-binding. > > A suggestion, we should try to phase out old system of reviews gradually, > instead of forcing it over a night. I agree. Maybe a time bound switch? We can say > like in x months from now we will completely move to PRs?

Re: Official Kafka Gitter Room?

Hi Gwen, On Sun, Jul 19, 2015 at 2:26 AM, Gwen Shapira wrote: > So, as an experiment, I created: > https://apachekafka.slack.com > > I figured we'll give it a whirl for a week or two for dev discussions, > see how it goes and if we have activity we can add this to the website > and announce on t

Re: Review Request 36670: Patch for KAFKA-2355

ve it to be in the `e: TopicAlreadyMarkedForDeletionException` clause maybe? - Ismael Juma On July 22, 2015, 1:46 a.m., Edward Ribeiro wrote: > > --- > This is an automatically generated e-mail. To reply, visit: >

Re: Review Request 36664: Patch for KAFKA-2353

ateException` and `IllegalArgumentException` are enough? Also, you would it be better to use `IOException` instead of `ClosedChannelException`? What happens if other exceptions are thrown? Will we still have a socket leak? - Ismael Juma On July 22, 2015, 5:02 a.m., Jiangj

Re: Kafka Unit Test Failures on a Mac

On Mon, Jul 20, 2015 at 10:45 PM, Grant Henke wrote: > In one run of the core tests I found the following: > >- 4584 regular files (REG) >- 376 .jar files > - Not much one can/should do here. Many are from gradle itself. > - 2392 kafka .log files > - why are these

Re: Review Request 33620: Patch for KAFKA-1690

pache/kafka/common/network/SSLFactory.java (line 199) <https://reviews.apache.org/r/33620/#comment146804> You can use try with resources now that we require Java 7. - Ismael Juma On July 20, 2015, 7 p.m., Sriharsha Chintalapani wrote: > > ---

Re: Review Request 33620: Patch for KAFKA-1690

/SSLTransportLayer.java (lines 46 - 57) <https://reviews.apache.org/r/33620/#comment146806> Some of these fields can be `final`. - Ismael Juma On July 20, 2015, 7 p.m., Sriharsha Chintalapani wrote: > > --- > This is an automatica

Re: [VOTE] Switch to GitHub pull requests for new contributions

Hi, On 22 Jul 2015 19:32, "Jiangjie Qin" wrote: > > +1 (non binding) > > Can we have a wiki for procedure and let people verify the steps? After > that we can update the Apache project page. Yes, I linked to the page in the original message: https://cwiki.apache.org/confluence/display/KAFKA/Con

Re: Review Request 36664: Patch for KAFKA-2353

> On July 22, 2015, 10:40 a.m., Ismael Juma wrote: > > core/src/main/scala/kafka/network/SocketServer.scala, line 467 > > <https://reviews.apache.org/r/36664/diff/2/?file=1018375#file1018375line467> > > > > As far as I can see `ClosedChannelException`,

Re: Review Request 36664: Patch for KAFKA-2353

> On July 22, 2015, 10:40 a.m., Ismael Juma wrote: > > core/src/main/scala/kafka/network/SocketServer.scala, line 467 > > <https://reviews.apache.org/r/36664/diff/2/?file=1018375#file1018375line467> > > > > As far as I can see `ClosedChannelException`,

Re: Review Request 36664: Patch for KAFKA-2353

> On July 21, 2015, 11:15 p.m., Gwen Shapira wrote: > > core/src/main/scala/kafka/network/SocketServer.scala, line 465 > > > > > > Turns out that catching Throwable is a really bad idea: > > https://www.sumologic.co

Re: Review Request 36670: Patch for KAFKA-2355

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36670/#review92744 --- Ship it! Ship It! - Ismael Juma On July 23, 2015, 1:23 a.m

Re: Review Request 36670: Patch for KAFKA-2355

> On July 23, 2015, 12:37 a.m., Edward Ribeiro wrote: > > core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala, line 269 > > > > > > I disagree because we are issuing two `deleteTopic` operations, the > > firs

Re: Review Request 36681: Patch for KAFKA-2275

> On July 23, 2015, 7:19 a.m., Ashish Singh wrote: > > core/src/test/scala/integration/kafka/api/ConsumerTest.scala, line 198 > > > > > > I don't think it is an issue. Hope it's OK to drop the issue. Thanks > > for

Re: Review Request 32841: Patch for KAFKA-2041

KeyProvider`. Let's see what others say though. - Ismael Juma On July 18, 2015, 2:46 a.m., benoyantony wrote: > > --- > This is an automatically generated e-mail. To reply, visit:

Re: Build failed in Jenkins: KafkaPreCommit #161

On Thu, Jul 23, 2015 at 5:39 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > > BUILD FAILED > This build job seems to be failing almost every time: https://builds.apache.org/job/KafkaPreCommit/ Also, it seems to be running at a similar time as: https://builds.apache.org/job/Kafk

Re: Review Request 36664: Patch for KAFKA-2353

> On July 22, 2015, 10:40 a.m., Ismael Juma wrote: > > core/src/main/scala/kafka/network/SocketServer.scala, line 401 > > <https://reviews.apache.org/r/36664/diff/2/?file=1018375#file1018375line401> > > > > Is it intentional to ignore `java.lang.Error` too?

Re: Build failed in Jenkins: KafkaPreCommit #161

On Thu, Jul 23, 2015 at 6:39 PM, Ashish Singh wrote: > Isamel, thats true. It will be nice to see this fixed, however as we are > now moving to Github PRs should we start using travis CI? > We are currently using Jenkins for PR builds: https://builds.apache.org/job/kafka-trunk-git-pr/ It would

Re: Kafka Indentation

Hi Jay, On Fri, Jul 24, 2015 at 2:00 AM, Jay Kreps wrote: > - Wait for java 8 to become common so we don't have to translate to java 7 > ... > Even ignoring those items I don't think we would dare take this on right > now because there are so many other projects in flight but it might be > worth

Re: [VOTE] Switch to GitHub pull requests for new contributions

Hi Ewen, On Fri, Jul 24, 2015 at 5:32 AM, Ewen Cheslack-Postava wrote: > > One other thing that might be worth mentioning in "The Review Process" > section is the hub tool: https://hub.github.com/ I only ever use one > feature, but it's immensely useful if you're reviewing PRs on Github. You > ca

Re: [VOTE] Switch to GitHub pull requests for new contributions

contribute. It is likely that people will move to the new way gradually and organically. At some point, a separate discussion may be started about requiring the new way, but let's see how it goes. Best, Ismael On Tue, Jul 21, 2015 at 12:28 PM, Ismael Juma wrote: > Hi all, > > I

Re: Kafka Indentation

On Fri, Jul 24, 2015 at 2:00 AM, Jay Kreps wrote: > I do agree that working with a mixture of scala and java is a pain in the > butt. What about considering the more extreme idea of just moving the > remaining server-side scala into java? I like Scala, but the tooling and > compatibility story fo

Re: [DISCUSS] KIP-28 - Add a transform client for data processing

On 24 Jul 2015 18:03, "Jay Kreps" wrote: > Does this make sense to people? If so let's try it and if we like it better > we can formally make that the process for this kind of big thing. Yes, sounds good to me. Best, Ismael

Re: Review Request 33620: Patch for KAFKA-1690

and idiomatic? i.e. `Map(key1 -> value1, key2 -> value2...)` core/src/test/scala/integration/kafka/api/ConsumerBounceTest.scala (line 99) <https://reviews.apache.org/r/33620/#comment147381> Left by mistake? - Ismael Juma On July 25, 2015, 7:11 p.m., Sriharsha Chintalapani wrot

Re: Review Request 33620: Patch for KAFKA-1690

> On July 27, 2015, 1:32 p.m., Ismael Juma wrote: > > core/src/main/scala/kafka/api/FetchResponse.scala, line 82 > > <https://reviews.apache.org/r/33620/diff/13/?file=1021998#file1021998line82> > > > > Casts are to be avoided in Scala, pattern matchin

Re: Review Request 36871: Patch for KAFKA-2381

/SubscriptionState.java (line 86) <https://reviews.apache.org/r/36871/#comment147616> A minor optimisation is to use `ArrayList` here to avoid rehashing the items in the list. - Ismael Juma On July 28, 2015, 4:59 a.m., Ashish Singh

Re: Review Request 36871: Patch for KAFKA-2381

, so can't say if this is the best way to do it (seems OK though). - Ismael Juma On July 28, 2015, 4:17 p.m., Ashish Singh wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.a

Re: Review Request 34492: Patch for KAFKA-2210

t`. core/src/test/scala/unit/kafka/security/auth/AclTest.scala (line 44) <https://reviews.apache.org/r/34492/#comment147698> Type annotation is generally not needed for local `vals` (there are a number of instances of this). - Ismael Juma On July 22, 2015, 12:08 a.m., Parth Brahmbhatt

Re: Build failed in Jenkins: KafkaPreCommit #167

It looks like two builds are running in the same workspace at the same time somehow. Ismael On Wed, Jul 29, 2015 at 1:44 AM, Guozhang Wang wrote: > Anyone knows how this "Could not open buildscript class" issue could happen > and can we fix it on our side or it is a general jenkins issue? > > G

[DISCUSS] Reviewers in commit message

Hi all, As a general rule, we credit reviewers in the commit message. This is good. However, it is not clear to me if there are guidelines on who should be included as a reviewer (please correct me if I am wrong). I can think of a few options: 1. Anyone that commented on the patch (in the pull

Re: Build failed in Jenkins: KafkaPreCommit #167

On Wed, Jul 29, 2015 at 4:52 PM, Guozhang Wang wrote: > It is likely that we make two commits at roughly the same time that > triggers two builds, how could this issue be resolve under this case? > It should not happen in a typical configuration, but hard to tell what is wrong without having acc

Re: [DISCUSS] Reviewers in commit message

Hi Gwen, Thanks for the feedback. Comments below. On Wed, Jul 29, 2015 at 6:40 PM, Gwen Shapira wrote: > The jira comment is a way for the committer to say "thank you" to > people who were involved in the review process. If we just want to say thank you, then why not just say that then? Using

Re: [DISCUSS] Reviewers in commit message

Hi Parth, On Wed, Jul 29, 2015 at 6:50 PM, Parth Brahmbhatt < pbrahmbh...@hortonworks.com> wrote: > +1 on Gwen¹s suggestion. > > Consider this as my thank you for all the reviews everyone has done in > past and are going to do in future. Don¹t make me say thanks on every > single commit. Introduc

Re: [DISCUSS] Reviewers in commit message

On Wed, Jul 29, 2015 at 7:38 PM, Gwen Shapira wrote: > I guess we see the "reviewer" part with different interpretations. > Yes. As you know, Git was created for and initially used by the Linux Kernel. As such they were very influential in conventions, terminology and best practices. This is wha

Re: Kafka Consumer thoughts

Hi Jay, Good points. A few remarks below. On Wed, Jul 29, 2015 at 11:16 PM, Jay Kreps wrote: > > I suggest we focus on threading and the current event-loop style of api > design since I think that is really the crux. > Agreed. I think ultimately though what you need to think about is, does an

Re: Review Request 28096: Patch for KAFKA-313

ot;` core/src/main/scala/kafka/admin/ConsumerGroupCommand.scala (line 339) <https://reviews.apache.org/r/28096/#comment147961> Typo: should be `numIterations`. core/src/main/scala/kafka/admin/ConsumerGroupCommand.scala (line 389) <https://reviews.apache.org/r/28096/#comment14794

Re: [DISCUSS] Reviewers in commit message

On Thu, Jul 30, 2015 at 6:04 PM, Gwen Shapira wrote: > I wasn't aware of this history, thanks for explaining! > No problem. :) In most Apache projects I contributed to, the list of things that are > stated in "reviewed by" are implied in a committer committing the > patch. Reviewers are there t

Re: Review Request 33620: Patch for KAFKA-1690

cers` should be vals. core/src/test/scala/integration/kafka/api/SSLConsumerTest.scala (line 218) <https://reviews.apache.org/r/33620/#comment148139> Code convention: space after `while`. There's a few more instances of this in the file.

Re: Review Request 33620: Patch for KAFKA-1690

> On July 31, 2015, 4:29 p.m., Sriharsha Chintalapani wrote: > > clients/src/main/java/org/apache/kafka/common/network/SSLTransportLayer.java, > > line 162 > > > > > > hasRemaining doesn't work here. Hence the reas

Re: Review Request 33620: Patch for KAFKA-1690

> On July 31, 2015, 4:32 p.m., Sriharsha Chintalapani wrote: > > core/src/test/scala/integration/kafka/api/SSLConsumerTest.scala, line 218 > > > > > > If we want to enforce this coding convention.Lets open up a new

Re: Review Request 33620: Patch for KAFKA-1690

> On July 27, 2015, 1:32 p.m., Ismael Juma wrote: > > clients/src/main/java/org/apache/kafka/common/config/SSLConfigs.java, line > > 29 > > <https://reviews.apache.org/r/33620/diff/13/?file=1021968#file1021968line29> > > > > SSL is deprecated >

Re: KAFKA-2364 migrate docs from SVN to git

On Fri, Jul 31, 2015 at 8:37 PM, Jay Kreps wrote: > The issue last time was that Apache has special infrastructure for web > hosting built around svn called svnpubsub. This is what takes the content > changes and pushes them live to the site. They didn't yet have a gitpubsub > at the time. If the

Re: Modified the contribution pages in the wiki

Thanks for making it clearer Gwen. One less item on my to-do list. :) More below. On Tue, Aug 4, 2015 at 11:56 PM, Gwen Shapira wrote: > There's always a plan! > > The contributor page only lists github as a valid contribution method. > > Theoretically the committers / reviewers should start ask

Re: Modified the contribution pages in the wiki

Hi Gwen, I moved some text from https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review to https://cwiki.apache.org/confluence/display/KAFKA/Patch+Review+Tool and made a few other minor tweaks. I think it's even clearer this way. Please let me know if you disagree. Thanks, I

Re: KAFKA-2364 migrate docs from SVN to git

Hi, For reference, here is the previous discussion on moving the website to Git: http://search-hadoop.com/m/uyzND11JliU1E8QU92 People were positive to the idea as Jay said. I would like to see a bit of a discussion around whether the website should be part of the same repo as the code or not. I'

Re: Review Request 34766: Patch for KAFKA-2229

> On Aug. 10, 2015, 3:47 p.m., Grant Henke wrote: > > My apologies for not looking at this sooner, or suggesting this sooner. > > Given that this code change and scope is fairly large, would it be too much > > work to break out the patches & reviews by each new protocol message? Then > > revie

Re: Review Request 37357: Upgrade LZ4 to version 1.3 to avoid crashing with IBM Java 7

f, len); } ` https://github.com/jpountz/lz4-java/blob/master/src/java-unsafe/net/jpountz/util/UnsafeUtils.java#L60 clients/src/main/java/org/apache/kafka/common/record/KafkaLZ4BlockOutputStream.java (line 183) <https://reviews.apache.org/r/37357/#comment149628> Same as above. - Isma

Re: Review Request 37357: Upgrade LZ4 to version 1.3 to avoid crashing with IBM Java 7

upstream library, it would probably be good to do more testing than just the unit tests. - Ismael Juma On Aug. 11, 2015, 6:56 p.m., Rajini Sivaram wrote: > > --- > This is an automatically generated e-mail. To reply, visit

Re: Kafka Indentation

On Wed, Aug 12, 2015 at 1:23 AM, Jason Gustafson wrote: > Can the java code be indented without affecting the results of git blame? > If not, then I'd vote to leave it as it is. > Nope. Ismael

Re: Kafka Indentation

On Wed, Aug 12, 2015 at 1:29 AM, Gwen Shapira wrote: > +1 on not breaking git blame > > -1 on rewriting Kafka in Java > +1 on upping our Scala game (as Ismael pointed out) > I filed a couple of JIRAs, and I'll look at introducing Scalastyle once some of the bigger patches/PRs are merged. https:

Re: KAFKA-2364 migrate docs from SVN to git

r-barrier benefits. > >> > > > > > > >> > > > > > Sqoop has the following process, which decouples documentation > >> > > changes > >> > > > > from > >> > > > > > website changes: > >> >

Re: NEW: API Stability annotations!

Hi Gwen, Nice to see this. There is no deprecation cycle for breakages? Ismael On Wed, Aug 12, 2015 at 11:05 PM, Gwen Shapira wrote: > Hi Team Kafka, > > Ewen just added stability annotations to Apache Kafka (KAFKA-2429). > > In the same PR, we marked the new Consumer API as "unstable" since w

Re: NEW: API Stability annotations!

On Thu, Aug 13, 2015 at 8:36 AM, Ewen Cheslack-Postava wrote: > On deprecation, I think we should definitely use the standard annotation to > handle this. Thanks Ewen. I agree that we should use @Deprecated for language-level deprecations. My question was regarding the following: - unstable -

Re: NEW: API Stability annotations!

On Thu, Aug 13, 2015 at 10:41 PM, Gwen Shapira wrote: > IMO, both old producer and old consumer APIs should be marked as deprecated > for 0.8.3 (since the new code will be in and we want to encourage the > switch). > I can see the appeal of this, but it's also worth considering the downsides for

Re: [DISCUSSION] Kafka 0.8.2.2 release?

I think this is a good idea as the change is minimal on our side and it has been tested in production for some time by the reporter. Best, Ismael On Fri, Aug 14, 2015 at 1:15 PM, Jun Rao wrote: > Hi, Everyone, > > Since the release of Kafka 0.8.2.1, a number of people have reported an > issue w

Re: Review Request 33620: Patch for KAFKA-1690

> On July 27, 2015, 1:32 p.m., Ismael Juma wrote: > > clients/src/main/java/org/apache/kafka/common/config/SSLConfigs.java, line > > 29 > > <https://reviews.apache.org/r/33620/diff/13/?file=1021968#file1021968line29> > > > > SSL is deprecated >

Re: Review Request 33620: Patch for KAFKA-1690

, the corrected description is: ``` * lists will be cleared at the beginning of each {@link #poll(long)} call and repopulated by the call if there is * any completed I/O.``` - Ismael Juma On Aug. 17, 2015, 3:41 a.m., Sriharsha Chintalapani wrote: > > -

Re: Review Request 33620: Patch for KAFKA-1690

at the word `any` was removed. - Ismael Juma On Aug. 17, 2015, 3:13 p.m., Sriharsha Chintalapani wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https:

Re: KAFKA-2364 migrate docs from SVN to git

l#comment-14703175 Best, Ismael On Wed, Aug 12, 2015 at 10:00 AM, Ismael Juma wrote: > Hi Gwen, > > I filed KAFKA-2425 as KAFKA-2364 is about improving the website > documentation. Aseem Bansal seemed interested in helping us with the move > so I pinged him in the issue. > > Bes

Re: KAFKA-2364 migrate docs from SVN to git

I should clarify: it's not possible unless we add an additional step that moves the docs from the code repo to the website repo. Ismael On Wed, Aug 19, 2015 at 4:42 PM, Ismael Juma wrote: > Hi all, > > It looks like it's not feasible to update the code and website in the

Re: Review Request 34492: Patch for KAFKA-2210

;https://reviews.apache.org/r/34492/#comment151143> @Test annotation is needed after you remove `JUnit3Suite`. This applies to all the tests. - Ismael Juma On Aug. 11, 2015, 1:32 a.m., Parth Brahmbhatt wrote: > >

Re: Review Request 34492: Patch for KAFKA-2210

the large SSL/TLS patch has now been merged (not sure if there are any conflicts). - Ismael Juma On Aug. 11, 2015, 1:32 a.m., Parth Brahmbhatt wrote: > > --- > This is an automatically generated e-mail. To reply, visit

Re: KAFKA-2364 migrate docs from SVN to git

cs directory with the latest revision > of > >> the > >> > > > docs > >> > > > > (not multiple versions, just one that matches the latest state > of > >> > code) > >> > > > > * When you submit a patch that require

Re: Review Request 34493: Patch for KAFKA-2211

? The answer may well be no, interested in your thoughts. core/src/main/scala/kafka/security/auth/SimpleAclAuthorizer.scala (line 146) <https://reviews.apache.org/r/34493/#comment151236> `inReadLock` returns a value. No need for the

Re: Review Request 36652: Patch for KAFKA-2351

> On Aug. 21, 2015, 5:57 p.m., Joel Koshy wrote: > > core/src/main/scala/kafka/network/SocketServer.scala, line 264 > > > > > > Thanks for the reference - we currently have this pattern all over the > > place. We ca

Re: Review Request 36652: Patch for KAFKA-2351

> On Aug. 21, 2015, 6:14 p.m., Joel Koshy wrote: > > core/src/main/scala/kafka/network/SocketServer.scala, line 264 > > > > > > Yes that's exactly what we need. Any reason why we shouldn't use > > `NonFatal` as is?

Re: Build failed in Jenkins: Kafka-trunk #595

Hmm, looks like something in Jenkins is different than my local setup. Will investigate and submit a follow-up. Ismael On Fri, Aug 21, 2015 at 8:10 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [cshapi

Re: Build failed in Jenkins: Kafka-trunk #595

Looks like I pushed an earlier iteration of the fix to the PR, sorry. Fix: https://github.com/apache/kafka/pull/159 Ismael On 21 Aug 2015 20:31, "Ismael Juma" wrote: > Hmm, looks like something in Jenkins is different than my local setup. > Will investigate and submit a follo

Re: Review Request 34493: Patch for KAFKA-2211

> On Aug. 21, 2015, 2:31 p.m., Ismael Juma wrote: > > Thanks for this Parth. I did an initial pass where I left a number comments > > (many of them style-related, see http://kafka.apache.org/coding-guide.html > > for reference). I know, we should have a tool that

Re: KAFKA-2364 migrate docs from SVN to git

that branch. > > > > git repo: https://git-wip-us.apache.org/repos/asf/kafka-site.git > > > > > > > > https://issues.apache.org/jira/browse/INFRA-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709630#comment-14709

Re: [DISCUSS] Time-based releases for Apache Kafka

Hi Gwen, Comments inline. On Wed, Aug 10, 2016 at 6:21 PM, Gwen Shapira wrote: > I hear what you are saying (enterprises upgrade every 2-years > more-or-less). It seems reasonable - this basically means maintaining > 10 compatibility tests at any point in time. Indeed. Although it's up to 6 t

[ANNOUCE] Apache Kafka 0.10.0.1 Released

ote, Edoardo Comar, Eno Thereska, Ewen Cheslack-Postava, Flavio Junqueira, Florian Hussonnois, Geoff Anderson, Grant Henke, Greg Fodor, Guozhang Wang, Gwen Shapira, Henry Cai, Ismael Juma, Jason Gustafson, Jeff Klukas, Jendrik Poloczek, Jeyhun Karimov, Liquan Pei, Manikumar Reddy O, Mathieu Fennia

[ANNOUCE] Apache Kafka 0.10.0.1 Released

ote, Edoardo Comar, Eno Thereska, Ewen Cheslack-Postava, Flavio Junqueira, Florian Hussonnois, Geoff Anderson, Grant Henke, Greg Fodor, Guozhang Wang, Gwen Shapira, Henry Cai, Ismael Juma, Jason Gustafson, Jeff Klukas, Jendrik Poloczek, Jeyhun Karimov, Liquan Pei, Manikumar Reddy O, Mathieu Fennia

Re: [DISCUSS] Time-based releases for Apache Kafka

Hi Joel, I think my suggestion was misunderstood. :) I suggested that we should support upgrades to the latest release for a reasonable period (and I used 2 years as an example). That doesn't mean supporting all of those branches for that period. It simply means that we maintain the code necessary

Re: [DISCUSS] Time-based releases for Apache Kafka

Do we need to make a decision on this particular point? Could we gauge community demand (people tend to ask for fixes to be backported in JIRA) and decide then? If we make a good job of avoiding regressions, then it seems that each branch should really only need one or or a maximum of two bug fix

<    5   6   7   8   9   10   11   12   13   14   >