Re: [VOTE] Graduate Kafka from Incubator to TLP status

+1 On 10/18/2012 07:03 PM, Jakob Homan wrote: > As discussed previously, Kafka is ready to graduate and we've drafted > resolution to make that happen. Resolution is now corrected from my overly > giraphy version (thanks, Joel for catching that): > > Please cast your votes: > > [ ] +1 Graduate

git wip incubator-kafka.git

https://issues.apache.org/jira/browse/INFRA-5111 Pleaes check out https://git-wip-us.apache.org/repos/asf/incubator-kafka.git (currently read only) and report on any issues. Joe and I were looking at the git mirror the other day (which this is based on) and didn't notice anything, so any bugs mus

Re: [DISCUSS] Kafka graduation resolution

t the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache Kafka Project: > > * Jun Rao > * Jay Kreps > * Neha Narkhede > * Jakob Homan > * Chris Burroughs > > NOW, THEREFORE, BE IT

Re: ??? 0.7.2 before 0.8 ???

On 2012-09-13 13:15, Joe Stein wrote: > I am working on a new product that has 0.7.1 in it don't mind even > pushing 0.7.2 into or 0.8 and releasing both in succession. Do yo want help with the mechanics of the release itself? On a tangentially related note with regards to branches I think the g

[jira] [Commented] (KAFKA-377) some of the dist mirrors are giving a 403

[ https://issues.apache.org/jira/browse/KAFKA-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13428534#comment-13428534 ] Chris Burroughs commented on KAFKA-377: --- I clicked through everything at h

Re: [DISCUSS] git as the primary data source

https://issues.apache.org/jira/browse/INFRA-5111 On 07/30/2012 08:40 PM, Chris Burroughs wrote: > I was originally going to follow this was a [VOTE] thread, but most of > the responses are a +1 anyway. I think we can do this and it will be a > significant improvement. I'll follow

Re: [DISCUSS] git as the primary data source

en > moving to git? If so, maybe it's better to wait until 0.8 is released. > > Jun > > On Mon, Jul 30, 2012 at 5:40 PM, Chris Burroughs > wrote: > >> I was originally going to follow this was a [VOTE] thread, but most of >> the responses are a +1 anyway. I

Re: [DISCUSS] git as the primary data source

o speak up. On 07/26/2012 11:39 AM, Chris Burroughs wrote: > It came up in the 0.7.2 thread that with the number of parallel branches > git may be preferable to svn for our current and future workflow. I'd > like to gauge interest in possibly switching from svn to git. > > Cu

Re: [DISCUSS] git as the primary data source

On 07/26/2012 02:43 PM, Joel Koshy wrote: > +1 for git in general - however, the apache git mirror has been working > pretty well for me for local work/code review. So if the caveats you > mention are significant enough then maybe we should stay on svn? I think the caveats are of the "things *coul

[jira] [Updated] (KAFKA-377) some of the dist mirrors are giving a 403

[ https://issues.apache.org/jira/browse/KAFKA-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-377: -- Fix Version/s: (was: 0.7.1) 0.7.2 > some of the dist mirrors

[DISCUSS] git as the primary data source

It came up in the 0.7.2 thread that with the number of parallel branches git may be preferable to svn for our current and future workflow. I'd like to gauge interest in possibly switching from svn to git. Currently INFRA can provide read/write git hosting at https://git-wip-us.apache.org/. Repos

Re: Are we doing a 0.7.2?

I think most people are using the > svn-git integration anyway. > > Anyone know the state of git support at apache? I heard other projects have > switched over. Is that generally available? > > Sent from my iPhone > > On Jul 26, 2012, at 5:31 AM, Chris Burroughs &g

Re: Are we doing a 0.7.2?

eha Narkhede wrote: > >> I think it might be useful for the community to have a couple more releases >> for 0.7.*, at least until 0.8 is fully stable. >> >> Thanks, >> Neha >> >> On Wed, Jul 18, 2012 at 1:03 PM, Chris Burroughs >> wrote: >

[jira] [Commented] (KAFKA-203) Improve Kafka internal metrics

[ https://issues.apache.org/jira/browse/KAFKA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417643#comment-13417643 ] Chris Burroughs commented on KAFKA-203: --- I also have metrics all over the plac

Re: Are we doing a 0.7.2?

I added a 0.7.2 release in JIRA for you (Joe, do you have the bits flipped to be able to do this?) On 07/18/2012 02:05 PM, Joe Stein wrote: > I was thinking we would have a 0.7.2 release if there are patches in trunk > that folks want to use, why not release them and make it available for > them?

[jira] [Commented] (KAFKA-377) some of the dist mirrors are giving a 403

[ https://issues.apache.org/jira/browse/KAFKA-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417625#comment-13417625 ] Chris Burroughs commented on KAFKA-377: --- INFRA-4975 is closed now, we good

Re: Incubator PMC/Board report for Jul 2012 ([ppmc])

Thanks Joel. On 07/03/2012 01:01 AM, Joel Koshy wrote: > Hi - added this to the wiki. Alan, can you review/sign-off? > > Thanks, > > Joel > > On Mon, Jul 2, 2012 at 5:02 PM, Joel Koshy wrote: > >> Looks like I don't have write access to the incubator wiki, and I have >> requested it. Meanwhil

Re: Build emails

them are passing except for 0.8. To deal with a new branch clone one of the existing jobs. It relies on executing ./sbt from the command line which sacrifices a lot of jenkins awesomeness. Hopefully a newer version of sbt has better integration. On 06/18/2012 10:29 PM, Chris Burroughs wrote

Re: RC3 status

On 06/25/2012 11:11 AM, Joe Stein wrote: > Let me suggest we do a 0.7.2 release later in July. I will volunteer to > manage that release also. You are a releasing hero!

Re: RC3 status

On 06/25/2012 12:07 AM, Neha Narkhede wrote: > Also, a lot of users have asked the release jar to be available > through Maven. It will be great to have that. Not sure if this was in reference to 0.7.1 or 0.7.2, but wouldn't a jar be a "binary" release? To the extend that is agreed to be a meaning

rm old RC tags

As a matter of cleanliness I'd like to remove the old (ie not final) RC tags from 0.7.0-*. Does anyone have any objections?

remaining jars in svn (was Fwd: Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2))

My interpretation of the long "Binary dependencies in source releases" thread is that the build tools are (I think) defensible, but it really would be best if we could get rid of the rest. I see that Neha and Jacob already did most of the work last round in KAFKA-222 (go team!). In the comments p

Build emails

Currently our jenkins build does not send email. This was my original preference (hordes of machine emails scare people away from subscribing). If others would prefer to see build emails sent somewhere let me know. https://builds.apache.org/job/Kafka-trunk/

Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)

I don't think we should release as is. - project.version is set to 0.7.0 - Have not released since the general@ threads highlighted the included jars problem. Thanks for pointing that out Kevan. (The unit test also don't pass for me but that could easily be a local issue, I'll try to get a branc

Re: Consumer re-design proposal

On 06/12/2012 12:59 PM, Jay Kreps wrote: >2. Try to replace the "simple consumer" and "high level consumer" with a >single, general interface that has all the advantages of both. I've read through the wiki pages but think I'm missing the forrest for the trees. For a consumer that wants "M

Re: video recording for the 1st Kafka user group meeting

On 06/15/2012 10:21 AM, Jun Rao wrote: > Thanks for everyone who showed up for the user group meeting last night. It > was a good turnout and was very interactive. If you missed the event, the > video recording can be found at > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+pre

Re: Solution for blocking fsync in 0.8

Thanks Jay. This is a very helpful investigation! On 05/24/2012 01:40 PM, Jay Kreps wrote: > > Unfortunately *any* call to fsync will block appends even in a background > thread so how can we give control over physical disk persistence without > introducing high latency for the producer? The ans

Emeritus Committer status

A while ago [1] in the "committer and pmc requirements" thread emeritus status came up (Alan's description quoted below). But I don't think there was consensus (or at least I could not find followup in the archives). Is this something we agree is a good idea? > Why emeritus? I think that it's i

Re: [DISCUSS] Graduate from incubator?

On 2012-05-23 23:32, Alan D. Cabrera wrote: >> We struggled a bit with licensing and packaging issues but we got those >> issues resolved and did a release and this should be pretty easy going >> forward. This is the one point I am hesitant about. I think it would be reasonable to ask us for a hi

Re: Incubator PMC/Board report for Apr 2012 ([ppmc])

A few comments: - Qualitative description is good, would you mine pulling the numbers for -dev -user mailing list traffic for embellishment? - Last time [1] we raised to the Incubator PMC/Board issues with regard to our release attempts. We have not released since (I *think* for unrelated reason

Re: committer and pmc requirements

Where Jay has set the bar for now sounds good to me. Yeah review-before-commit! I think the long term goal of committers == PMC is the right one. While I am not sure if they have it set as formal policy it seems common on projects I have observed for new committers to become PMC members $n$ mont

Re: kafka.utils.Utils

It would also be nice if the truly generic ZKUtils (createEphemeralPathExpectConflict) and the kafka specific (getConsumersPerTopic) were in separate classes. On 03/25/2012 06:23 PM, Jay Kreps wrote: > Hey guys, > > The Utils helpers are meant to be generic non-kafka-specific utility > functions.

[jira] [Commented] (KAFKA-230) Update website documentation to include changes in 0.7.0 release

[ https://issues.apache.org/jira/browse/KAFKA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179555#comment-13179555 ] Chris Burroughs commented on KAFKA-230: --- The download link goes directl

[jira] [Commented] (KAFKA-230) Update website documentation to include changes in 0.7.0 release

[ https://issues.apache.org/jira/browse/KAFKA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179002#comment-13179002 ] Chris Burroughs commented on KAFKA-230: --- See http://incubator.apache.org/gu

Re: Would a source only 0.7.0 release be better?

On 12/03/2011 02:40 PM, Chris Burroughs wrote: > My reading is that since we would only be distributing source code, the > NOTICE file should not reflect binary dependencies and would have *only* > the standard Apache bit [3]. Same for LICENSE. I suppose any jar's checked

Would a source only 0.7.0 release be better?

It was suggested on general@ that a source only release reduces the number of requirements with regards to dealing with (transitive) dependencies and NOTICE files [1]. I can't recall if this is new or not but the release guide also currently suggests them for early projects [2]. My reading is tha

Re: Guide to Writing a Client for Kafka

Great work! Having a solid doc/spec for the wire protocol would also likely decrease the need to have as many clients in-tree. I think at this point that would be a good thing. On 11/23/2011 06:32 PM, David Ormsbee wrote: > Hi folks, > > Inspired by the Wire Format wiki entry, I recently create

[jira] [Created] (KAFKA-218) ZOOKEEPER-961 is nasty, upgrade to zk 3.3.4

ZOOKEEPER-961 is nasty, upgrade to zk 3.3.4 --- Key: KAFKA-218 URL: https://issues.apache.org/jira/browse/KAFKA-218 Project: Kafka Issue Type: Bug Reporter: Chris Burroughs

[jira] [Commented] (KAFKA-216) Add nunit license to the NOTICE file

[ https://issues.apache.org/jira/browse/KAFKA-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159503#comment-13159503 ] Chris Burroughs commented on KAFKA-216: --- Could you add something like "

[jira] [Commented] (KAFKA-203) Improve Kafka internal metrics

[ https://issues.apache.org/jira/browse/KAFKA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155970#comment-13155970 ] Chris Burroughs commented on KAFKA-203: --- I *think* metrics is source compatible

[jira] [Commented] (KAFKA-134) Upgrade Kafka to sbt 0.10.1

[ https://issues.apache.org/jira/browse/KAFKA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155962#comment-13155962 ] Chris Burroughs commented on KAFKA-134: --- Is 0.10 still the most recent version

[jira] [Commented] (KAFKA-204) BoundedByteBufferReceive hides OutOfMemoryError

[ https://issues.apache.org/jira/browse/KAFKA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155857#comment-13155857 ] Chris Burroughs commented on KAFKA-204: --- > I mean once you hit that all bets

[jira] [Updated] (KAFKA-206) no DISCLAIMER, NOTICE needs cleanup

[ https://issues.apache.org/jira/browse/KAFKA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-206: -- Attachment: k206-v1.txt Still not sure which things actually need to be mentioned in the NOTICE

[jira] [Created] (KAFKA-206) no DISCLAIMER, NOTICE needs cleanup

no DISCLAIMER, NOTICE needs cleanup --- Key: KAFKA-206 URL: https://issues.apache.org/jira/browse/KAFKA-206 Project: Kafka Issue Type: Bug Affects Versions: 0.7 Reporter: Chris Burroughs

[jira] [Created] (KAFKA-205) Audit swallowing of exceptions/throwables

Audit swallowing of exceptions/throwables - Key: KAFKA-205 URL: https://issues.apache.org/jira/browse/KAFKA-205 Project: Kafka Issue Type: Task Reporter: Chris Burroughs There are

[jira] [Commented] (KAFKA-204) BoundedByteBufferReceive hides OutOfMemoryError

[ https://issues.apache.org/jira/browse/KAFKA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151220#comment-13151220 ] Chris Burroughs commented on KAFKA-204: --- Tiny patch for this one case, created K

[jira] [Updated] (KAFKA-204) BoundedByteBufferReceive hides OutOfMemoryError

[ https://issues.apache.org/jira/browse/KAFKA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-204: -- Attachment: k204-v1.txt > BoundedByteBufferReceive hides OutOfMemoryEr

[jira] [Updated] (KAFKA-204) BoundedByteBufferReceive hides OutOfMemoryError

[ https://issues.apache.org/jira/browse/KAFKA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-204: -- Assignee: Chris Burroughs > BoundedByteBufferReceive hides OutOfMemoryEr

[jira] [Created] (KAFKA-204) BoundedByteBufferReceive hides OutOfMemoryError

Reporter: Chris Burroughs Priority: Critical private def byteBufferAllocate(size: Int): ByteBuffer = { var buffer: ByteBuffer = null try { buffer = ByteBuffer.allocate(size) } catch { case e: OutOfMemoryError => throw new RuntimeException("OOME w

Re: Proposal: fixed release schedule

cluster of Kafka brokers using 0.8 >> (can potentially overlay on existing hardware). Then upgrade all producers >> and point them to the new brokers. Drain all old consumers. Upgrade all >> consumers and point them to the new brokers. >> >> What do people feel about t

Re: Proposal: fixed release schedule

On 11/11/2011 06:01 PM, Jay Kreps wrote: > 2. Our current focus for linkedin folks was going to be on replication >which will be a really disruptive set of features that need to be released >together. I think there are some differing assumptions on the impact of replication. My assumptio

Proposal: fixed release schedule

With kafka 0.7 almost (*crosses fingers*) out I wanted to propose we adopt a fixed release schedule for major releases instead of by feature. So that -- for example -- we set a freeze date for 0.8.0 that is n weeks/months after 0.7.0 is completely out the door (something in the 2-4 month range per

Re: [jira] [Updated] (KAFKA-187) Add Snappy Compression as a Codec and refactor CompressionUtil and option on startup to select what the default codec

On 11/11/2011 01:55 PM, Jeffrey Damick wrote: > So with regard to the > KAFKA-187 what > is the stance going to be on supporting new compression methods? Is it > expected that all clients 'must' & will support them? If not, is there a > set of 'req

Re: [VOTE] Release Kafka 0.7.0 incubating candidate 6

+1 On 11/08/2011 04:23 PM, Neha Narkhede wrote: > Hi, > This is the sixth candidate for the first incubator release for Apache > Kafka, version 0.7.0-incubating. There were a few binary distribution > related concerns in the last RC. This candidate is published to fix those, > and include all depe

[jira] [Commented] (KAFKA-196) Topic creation fails on large values

[ https://issues.apache.org/jira/browse/KAFKA-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148024#comment-13148024 ] Chris Burroughs commented on KAFKA-196: --- '/' is particularly compli

[jira] [Commented] (KAFKA-186) no clean way to getCompressionCodec from Java-the-language

[ https://issues.apache.org/jira/browse/KAFKA-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144248#comment-13144248 ] Chris Burroughs commented on KAFKA-186: --- That requires everyone to write their

[jira] [Created] (KAFKA-186) no clean way to getCompressionCodec from Java-the-language

: 0.7 Reporter: Chris Burroughs The obvious thing fails: CompressionCodec.getCompressionCodec(1) results in cannot find symbol symbol : method getCompressionCodec(int) location: interface kafka.message.CompressionCodec Writing a switch statement with kafka.message.NoCompressionCodec

Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)

On 11/03/2011 03:41 PM, Alan D. Cabrera wrote: > Zowie. Look at all these jars that I have to make sure are kosher to > distribute: > > > Can someone help me? > Assuming we can cut down on the boot/test jars. All we need is a table of "jar-name,licence", correct?

Re: svn commit: r1188024 - /incubator/kafka/trunk/config/server.properties

On 10/24/2011 01:01 AM, jkr...@apache.org wrote: > Author: jkreps > Date: Mon Oct 24 05:01:40 2011 > New Revision: 1188024 > -# the port the socket server runs on > -port=9092 > +# Socket Server Settings > # > > -# the number of processor t

Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)

On 11/03/2011 04:11 PM, Chris Burroughs wrote: > To Alan and Jay's point, I don't think there is a need to distribut the > ./boot jars. > And I think the same applies to test dependencies.

Re: time for another attempt at a 0.7.0 release?

An example. On 10/31/2011 10:57 PM, Chris Burroughs wrote: > Similar information, but different audience. This is about summarising > only what has changed and is operational relevant (special pre/post > upgrade procedure or in this case upgrade order) in plain language. >

Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)

To Alan and Jay's point, I don't think there is a need to distribut the ./boot jars. I thought we went over the rest in KAFKA-142, but looking back it doesn't sound as definitive. On 11/03/2011 03:41 PM, Alan D. Cabrera wrote: > Zowie. Look at all these jars that I have to make sure are kosher t

Re: time for another attempt at a 0.7.0 release?

at address the concern you are > raising ? > > Thanks, > Neha > > On Mon, Oct 31, 2011 at 7:21 PM, Chris Burroughs > wrote: >> On 10/31/2011 06:55 PM, Neha Narkhede wrote: >>> Chris, please could you elaborate a little more on this ? I think if >>> thi

Re: time for another attempt at a 0.7.0 release?

On 10/31/2011 06:55 PM, Neha Narkhede wrote: > Chris, please could you elaborate a little more on this ? I think if > this is a small change, we can cut the RC today. > I think we ought to include a NEWS file for users upgading from a previous version. Projects varry in how they do this, some ex

Re: KAFKA-50 replication support and the Disruptor

On 10/31/2011 04:23 AM, Erik van Oosten wrote: > That is not the point (mostly). While you're waiting for a lock, you can't > issue another IO request. Avoiding locking is worthwhile even if CPU is the > bottleneck. The advantage is that you'll get lower latency and also > important, less jitter

time for another attempt at a 0.7.0 release?

https://issues.apache.org/jira/browse/KAFKA/fixforversion/12317243 I don't seen any open issues listed.

Re: removing not well maintained clients

Fine with me. On 10/27/2011 12:43 AM, Jun Rao wrote: > OK, how about we remove the closure client for now, since it is not a thin > wrapper and is not being maintained. Any objections? > > Thanks, > > Jun > > On Wed, Oct 26, 2011 at 5:58 PM, Chris Burroughs > wrote

Re: removing not well maintained clients

On 10/25/2011 12:41 PM, Jun Rao wrote: > We are getting close to cut a new RC for 0.7 release. Before we do that, I > want to ask people's opinion about those not well maintained non-java > clients. Currently, at least Ruby and Closure are not well maintained > (little or no activities). I am think

Re: perf testing

On 10/24/2011 03:27 PM, Neha Narkhede wrote: > % busy - indicates how busy the disks are. To my knowledge there isn't a god way to get this if disks is > 1. iostat's %util becomes "percent of time waiting on at least one disk".

[jira] [Commented] (KAFKA-139) cross-compile multiple Scala versions

[ https://issues.apache.org/jira/browse/KAFKA-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136639#comment-13136639 ] Chris Burroughs commented on KAFKA-139: --- Agreed that the need

[jira] [Commented] (KAFKA-174) Add performance suite for Kafka

[ https://issues.apache.org/jira/browse/KAFKA-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136635#comment-13136635 ] Chris Burroughs commented on KAFKA-174: --- - If you are willing to ask OS t

[jira] [Commented] (KAFKA-170) Support for non-blocking polling on multiple streams

[ https://issues.apache.org/jira/browse/KAFKA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136630#comment-13136630 ] Chris Burroughs commented on KAFKA-170: --- > Do users care about the topic/pa

[jira] [Commented] (KAFKA-171) Kafka producer should do a single write to send message sets

[ https://issues.apache.org/jira/browse/KAFKA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136622#comment-13136622 ] Chris Burroughs commented on KAFKA-171: --- Even if this doesn't measurabl

Re: layering

This is great. I know there are a lot of different use cases: embedded vs standalone, some people want to avoid the ZK dependency etc. This will help us keep them all straight. On 10/25/2011 12:54 AM, Jay Kreps wrote: > Hey guys, > > I am seeing a few places where code is kind of growing togeth

[jira] [Updated] (KAFKA-91) zkclient does not show up in pom

[ https://issues.apache.org/jira/browse/KAFKA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-91: - Attachment: k91-v2.txt Sorry missed your reply, rebased as of

[jira] [Commented] (KAFKA-91) zkclient does not show up in pom

[ https://issues.apache.org/jira/browse/KAFKA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134381#comment-13134381 ] Chris Burroughs commented on KAFKA-91: -- Our custom build of zkclient isn't in

[jira] [Commented] (KAFKA-91) zkclient does not show up in pom

[ https://issues.apache.org/jira/browse/KAFKA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134364#comment-13134364 ] Chris Burroughs commented on KAFKA-91: -- Could I get a re

[jira] [Commented] (KAFKA-150) Confusing NodeExistsException failing kafka broker startup

[ https://issues.apache.org/jira/browse/KAFKA-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134365#comment-13134365 ] Chris Burroughs commented on KAFKA-150: --- trunk is still 0.7, r

[jira] [Commented] (KAFKA-166) Create a tool to jump JMX data to a csv file to help build out performance tests

[ https://issues.apache.org/jira/browse/KAFKA-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134056#comment-13134056 ] Chris Burroughs commented on KAFKA-166: --- Coda Hale's metrics package has

[jira] [Commented] (KAFKA-164) Config should default to a higher-throughput configuration for log.flush.interval

[ https://issues.apache.org/jira/browse/KAFKA-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131854#comment-13131854 ] Chris Burroughs commented on KAFKA-164: --- There are good things to be said a

[jira] [Commented] (KAFKA-153) Add compression to C# client

[ https://issues.apache.org/jira/browse/KAFKA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129985#comment-13129985 ] Chris Burroughs commented on KAFKA-153: --- Is this something we want to re-spin

Re: Our first release

On 10/17/2011 02:22 PM, Alan D. Cabrera wrote: > Under the "Versions" tab there should be a "Manage Versions" link on the > right side. I don't see "Manage Versions" :-(

Re: [jira] [Updated] (KAFKA-153) Add compression to C# client

Is this something we want to re-spin the release on, start work on a 0.7.1? On 10/18/2011 01:53 PM, Jun Rao (Updated) (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/KAFKA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Jun Rao updated KAFKA-153:

[jira] [Commented] (KAFKA-50) kafka intra-cluster replication support

[ https://issues.apache.org/jira/browse/KAFKA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129830#comment-13129830 ] Chris Burroughs commented on KAFKA-50: -- > I would even argue that if possibl

[jira] [Commented] (KAFKA-156) Messages should not be dropped when brokers are unavailable

[ https://issues.apache.org/jira/browse/KAFKA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129301#comment-13129301 ] Chris Burroughs commented on KAFKA-156: --- Perhaps the producers themselves sh

Re: Our first release

On 10/10/2011 11:08 PM, Alan D. Cabrera wrote: > > On Oct 10, 2011, at 5:46 PM, Chris Burroughs wrote: > >> On 10/02/2011 12:16 PM, Alan D. Cabrera wrote: >>> I assume that our first release will be 0.6. Is that correct? >> >> Could someone close the old

[jira] [Commented] (KAFKA-156) Messages should not be dropped when brokers are unavailable

[ https://issues.apache.org/jira/browse/KAFKA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129024#comment-13129024 ] Chris Burroughs commented on KAFKA-156: --- Sorry, wrong "we". I mean

Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 3)

On 10/14/2011 03:44 PM, Alan D. Cabrera wrote: > That's fine. What do others in the community think about this? Were > they counting on a release of Maven artifacts as well? If that's > what is everyone's understanding then the release should be good on > this front. My expectation was that mav

[jira] [Commented] (KAFKA-156) Messages should not be dropped when brokers are unavailable

[ https://issues.apache.org/jira/browse/KAFKA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129018#comment-13129018 ] Chris Burroughs commented on KAFKA-156: --- This is more or less what we do

Re: Incubator PMC/Board report for October 2011 (kafka-dev@incubator.apache.org)

Alan, can we still report and get signoff today. Or is the 12th deadline a hard one? On 10/01/2011 10:00 AM, no-re...@apache.org wrote: > Dear Kafka Developers, > > This email was sent by an automated system on behalf of the Apache Incubator > PMC. > It is an initial reminder to give you plenty

Re: Incubator PMC/Board report for October 2011 (kafka-dev@incubator.apache.org)

On 10/02/2011 11:44 AM, Jun Rao wrote: > I will do that. Hopefully we will have our first Apache release by then. > Jun, would you like any help with the report? /end-reminder

Re: Our first release

On 10/02/2011 12:16 PM, Alan D. Cabrera wrote: > I assume that our first release will be 0.6. Is that correct? Could someone close the old 0.6 jira milestone?

KEYS file location

We have two KEYS files at root/KEYS and trunk/KEYS. Which is the correct location?

[jira] [Updated] (KAFKA-91) zkclient does not show up in pom

[ https://issues.apache.org/jira/browse/KAFKA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-91: - Attachment: k91-v1.txt This magic incantation appears to work. > zkclient d

[jira] [Updated] (KAFKA-91) zkclient does not show up in pom

[ https://issues.apache.org/jira/browse/KAFKA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-91: - Status: Patch Available (was: Open) > zkclient does not show up in

[jira] [Updated] (KAFKA-152) Include payload size in DumpLogSegments

[ https://issues.apache.org/jira/browse/KAFKA-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-152: -- Status: Patch Available (was: Open) > Include payload size in DumpLogSegme

[jira] [Updated] (KAFKA-152) Include payload size in DumpLogSegments

[ https://issues.apache.org/jira/browse/KAFKA-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Burroughs updated KAFKA-152: -- Attachment: k152-v1.txt > Include payload size in DumpLogSegme

[jira] [Created] (KAFKA-152) Include payload size in DumpLogSegments

: Chris Burroughs Assignee: Chris Burroughs Priority: Minor It's handy for debugging large and unprintable messages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org

Re: svn commit: r1180110 [1/2] - in /incubator/kafka/trunk: ./ bin/ clients/clojure/ clients/clojure/leiningen/ clients/clojure/resources/ clients/clojure/src/kafka/ clients/clojure/test/kafka/ client

On 10/09/2011 04:10 PM, Neha Narkhede wrote: > I wondered if it was lying around from the time when Kafka was hosted > on github. Thought we have forgotten to clean it up when we moved to > Apache. Ah okay, makes sense. I added it in r1153592 for git (and git-svn) users. Will restore.

[jira] [Commented] (KAFKA-142) Check and make sure that for all code included with the distribution that is not under the Apache license, we have the right to combine with Apache-licensed code and red

[ https://issues.apache.org/jira/browse/KAFKA-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124100#comment-13124100 ] Chris Burroughs commented on KAFKA-142: --- Sorry, I meant the *dependencies

  1   2   3   >