Re: Apache Kafka JIRA Worflow: Add Closed -> Reopen transition
Thanks Manikumar, I had previously tried to fix the issue below but couldn't because JIRA did not allow the issue to be reopened. So, I think this is a good change. We can revisit if it becomes an issue. And thanks for all your help cleaning up JIRA (both via closing stale issues as well as fixing bugs yourself). :) Ismael On 21 May 2016 07:26, "Manikumar Reddy" wrote: > Hi, > > There were some jiras which are closed but not resolved. > I just wanted to close those jiras properly, so that they won't > appear in jira search. Without this new transition i was not able close > them properly. > > Manikumar > On May 21, 2016 11:23 AM, "Harsha" wrote: > > > Manikumar, > > Any reason for this. Before the workflow is to open > > a new JIRA if a JIRA closed. > > -Harsha > > > > On Fri, May 20, 2016, at 08:54 PM, Manikumar Reddy wrote: > > > Jun/Ismail, > > > > > > I requested Apache Infra to change JIRA workflow to add Closed -> > > > Reopen > > > transition. > > > https://issues.apache.org/jira/browse/INFRA-11857 > > > > > > Let me know, If any concerns > > > > > > Manikumar > > >
[DISCUSS] scalability limits in the coordinator
Hey everyone. So I started doing some tests on the new consumer/coordinator to see if it could handle more strenuous use cases like mirroring clusters with thousands of topics and thought I'd share whatever I have so far. The scalability limit: the amount of group metadata we can fit into one message Some background: Client-side assignment is implemented in two phases 1. a PreparingRebalance phase that identifies members of the group and aggregates member subscriptions. 2. an AwaitingSync phase that waits for the group leader to decide member assignments based on the member subscriptions across the group. - The leader announces this decision with a SyncGroupRequest. The GroupCoordinator handles SyncGroupRequests by appending all group state into a single message under the __consumer_offsets topic. This message is keyed on the group id and contains each member subscription as well as the decided assignment for each member. The environment: - one broker - one __consumer_offsets partition - offsets.topic.compression.codec=1 // this is gzip - broker has my pending KAFKA-3718 patch that actually makes use of offsets.topic.compression.codec: https://github.com/apache/kafka/pull/1394 - around 3000 topics. This is an actual subset of topics from one of our clusters. - topics have 8 partitions - topics are 25 characters long on average - one group with a varying number of consumers each hardcoded with all the topics just to make the tests more consistent. wildcarding with .* should have the same effect once the subscription hits the coordinator as the subscription has already been fully expanded out to the list of topics by the consumers. - I added some log messages to Log.scala to print out the message sizes after compression - there are no producers at all and auto commits are disabled. The only topic with messages getting added is the __consumer_offsets topic and they're only from storing group metadata while processing SyncGroupRequests. Results: The results below show that we exceed the 112 byte KafkaConfig.messageMaxBytes limit relatively quickly (between 30-40 consumers): 1 consumer 54739 bytes 5 consumers 261524 bytes 10 consumers 459804 bytes 20 consumers 702499 bytes 30 consumers 930525 bytes 40 consumers 1115657 bytes * the tipping point 50 consumers 1363112 bytes 60 consumers 1598621 bytes 70 consumers 1837359 bytes 80 consumers 2066934 bytes 90 consumers 2310970 bytes 100 consumers 2542735 bytes Note that the growth itself is pretty gradual. Plotting the points makes it look roughly linear w.r.t the number of consumers: https://www.wolframalpha.com/input/?i=(1,+54739),+(5,+261524),+(10,+459804),+(20,+702499),+(30,+930525),+(40,+1115657),+(50,+1363112),+(60,+1598621),+(70,+1837359),+(80,+2066934),+(90,+2310970),+(100,+2542735) Also note that these numbers aren't averages or medians or anything like that. It's just the byte size from a given run. I did run them a few times and saw similar results. Impact: Even after adding gzip to the __consumer_offsets topic with my pending KAFKA-3718 patch, the AwaitingSync phase of the group fails with RecordTooLargeException. This means the combined size of each member's subscriptions and assignments exceeded the KafkaConfig.messageMaxBytes of 112 bytes. The group ends up dying. Options: 1. Config change: reduce the number of consumers in the group. This isn't always a realistic answer in more strenuous use cases like MirrorMaker clusters or for auditing. 2. Config change: split the group into smaller groups which together will get full coverage of the topics. This gives each group member a smaller subscription.(ex: g1 has topics starting with a-m while g2 has topics starting ith n-z). This would be operationally painful to manage. 3. Config change: split the topics among members of the group. Again this gives each group member a smaller subscription. This would also be operationally painful to manage. 4. Config change: bump up KafkaConfig.messageMaxBytes (a topic-level config) and KafkaConfig.replicaFetchMaxBytes (a broker-level config). Applying messageMaxBytes to just the __consumer_offsets topic seems relatively harmless, but bumping up the broker-level replicaFetchMaxBytes would probably need more attention. 5. Config change: try different compression codecs. Based on 2 minutes of googling, it seems like lz4 and snappy are faster than gzip but have worse compression, so this probably won't help. 6. Implementation change: support sending the regex over the wire instead of the fully expanded topic subscriptions. I think people said in the past that different languages have subtle differences in regex, so this doesn't play nicely with cross-language groups. 7. Implementation change: maybe we can reverse the mapping? Instead of mapping from member to subscriptions, we can map a subscription to a list of members. 8. Implementation change: maybe we can try to break apart the subscription and assignments from the same SyncGroupRequest into multiple re
[RESULTS] [VOTE] Release Kafka version 0.10.0.0
This vote passes with 9 +1 votes (4 bindings) and no 0 or -1 votes. +1 votes PMC Members: * Jay Kreps * Jun Rao * Guozhang Wang * Joe Stein Committers: * Sriharsha Chintalapani * Ewen Cheslack-Postava Community: * Dana Powers * Vahid S. Hashemian * Ashish Singh Vote thread:https://www.mail-archive.com/dev@kafka.apache.org/msg50182.html Thanks for participating in the long and painful release vetting process! I'll continue in the release process and announce a release in the next few days. Probably Monday or Tuesday :) Congrats everyone! Gwen
[jira] [Commented] (KAFKA-3709) Create project security page
[ https://issues.apache.org/jira/browse/KAFKA-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295087#comment-15295087 ] ASF GitHub Bot commented on KAFKA-3709: --- Github user junrao commented on the pull request: https://github.com/apache/kafka-site/pull/12#issuecomment-220784809 The mailing list has been created. We can invite all committers/contributors who are interested in security to join the list. secur...@kafka.apache.org Moderators: jun...@gmail.com,ism...@juma.me.uk,csh...@gmail.com This list is private. > Create project security page > > > Key: KAFKA-3709 > URL: https://issues.apache.org/jira/browse/KAFKA-3709 > Project: Kafka > Issue Type: Improvement > Components: website >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira > > We are creating a security@k.a.o mailing list to receive reports of potential > vulnerabilities. Now that Kafka has security in place, the community might > starts receiving vulnerability reports and we need to follow the guidelines > here: > http://www.apache.org/security/ > Specifically, security issues are better handled in a project-specific list. > This jira is to create a web page that informs users and contributors of how > we are supposed to handle security issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] kafka-site pull request: KAFKA-3709: Create a project security pag...
Github user junrao commented on the pull request: https://github.com/apache/kafka-site/pull/12#issuecomment-220784809 The mailing list has been created. We can invite all committers/contributors who are interested in security to join the list. secur...@kafka.apache.org Moderators: jun...@gmail.com,ism...@juma.me.uk,csh...@gmail.com This list is private. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (KAFKA-3632) ConsumerLag metrics persist after partition migration
[
https://issues.apache.org/jira/browse/KAFKA-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295113#comment-15295113
]
Otis Gospodnetic commented on KAFKA-3632:
-
Wow, could this be a fix for the problem described in this thread:
http://search-hadoop.com/m/uyzND1vNarT5XZpK&subj=Re+Consumer+lag+lies+orphaned+offsets
?
And could this be a related, or even a fix for KAFKA-2530?
> ConsumerLag metrics persist after partition migration
> -
>
> Key: KAFKA-3632
> URL: https://issues.apache.org/jira/browse/KAFKA-3632
> Project: Kafka
> Issue Type: Bug
> Components: core
>Affects Versions: 0.8.2.2, 0.9.0.1
> Environment: JDK 1.8, Linux
>Reporter: Brian Lueck
>Assignee: Jason Gustafson
>Priority: Minor
> Fix For: 0.10.0.0
>
>
> When a partition is migrated away from a broker, the ConsumerLag metric for
> the topic/partition gets 'stuck' at the current value. The only way to remove
> the metric is to restart the broker.
> This appears to be because in AbstractFetcherThread.scala there is no way of
> removing a metric. See...
> {code}
> class FetcherLagStats(metricId: ClientIdAndBroker) {
> private val valueFactory = (k: ClientIdTopicPartition) => new
> FetcherLagMetrics(k)
> val stats = new Pool[ClientIdTopicPartition,
> FetcherLagMetrics](Some(valueFactory))
> def getFetcherLagStats(topic: String, partitionId: Int): FetcherLagMetrics =
> {
> stats.getAndMaybePut(new ClientIdTopicPartition(metricId.clientId, topic,
> partitionId))
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] 0.10.0.0 RC6
+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. And the system tests passed on the 0.10.0 branch: https://jenkins.confluent.io/job/system-test-kafka-0.10.0/61/ Ismael On Sat, May 21, 2016 at 1:21 AM, Ashish Singh wrote: > +1, verified quickstart with source and binary release. > > On Saturday, May 21, 2016, Vahid S Hashemian > wrote: > > > +1. I was able to successfully create a topic and run a producer and > > consumer against it from the source on Ubuntu 15.04, Mac OS X Yosemite, > > and Windows 7. > > --Vahid > > > > > > > > From: Dana Powers > > > To: "dev@kafka.apache.org " > > > > Date: 05/20/2016 12:13 PM > > Subject:Re: [VOTE] 0.10.0.0 RC6 > > > > > > > > +1 -- passed kafka-python integration tests > > > > -Dana > > > > On Fri, May 20, 2016 at 11:16 AM, Joe Stein > > wrote: > > > +1 ran quick start from source and binary release > > > > > > On Fri, May 20, 2016 at 1:07 PM, Ewen Cheslack-Postava > > > > > > wrote: > > > > > >> +1 validated connect with a couple of simple connectors and console > > >> producer/consumer. > > >> > > >> -Ewen > > >> > > >> On Fri, May 20, 2016 at 9:53 AM, Guozhang Wang > > > > wrote: > > >> > > >> > +1. Validated maven (should be > > >> > > > https://repository.apache.org/content/groups/staging/org/apache/kafka/ > > >> > btw) > > >> > and binary libraries, quick start. > > >> > > > >> > On Fri, May 20, 2016 at 9:36 AM, Harsha > > wrote: > > >> > > > >> > > +1 . Ran a 3-node cluster with few system tests on our side. Looks > > >> good. > > >> > > > > >> > > -Harsha > > >> > > > > >> > > On Thu, May 19, 2016, at 07:47 PM, Jun Rao wrote: > > >> > > > Thanks for running the release. +1 from me. Verified the > > quickstart. > > >> > > > > > >> > > > Jun > > >> > > > > > >> > > > On Tue, May 17, 2016 at 10:00 PM, Gwen Shapira > > > > > >> > > wrote: > > >> > > > > > >> > > > > Hello Kafka users, developers and client-developers, > > >> > > > > > > >> > > > > This is the seventh (!) candidate for release of Apache Kafka > > >> > > > > 0.10.0.0. This is a major release that includes: (1) New > > message > > >> > > > > format including timestamps (2) client interceptor API (3) > > Kafka > > >> > > > > Streams. > > >> > > > > > > >> > > > > This RC was rolled out to fix an issue with our packaging that > > >> caused > > >> > > > > dependencies to leak in ways that broke our licensing, and an > > issue > > >> > > > > with protocol versions that broke upgrade for LinkedIn and > > others > > >> who > > >> > > > > may run from trunk. Thanks to Ewen, Ismael, Becket and Jun for > > the > > >> > > > > finding and fixing of issues. > > >> > > > > > > >> > > > > Release notes for the 0.10.0.0 release: > > >> > > > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/RELEASE_NOTES.html > > >> > > > > > > >> > > > > Lets try to vote within the 72h release vote window and get > > this > > >> baby > > >> > > > > out already! > > >> > > > > > > >> > > > > *** Please download, test and vote by Friday, May 20, 23:59 PT > > >> > > > > > > >> > > > > Kafka's KEYS file containing PGP keys we use to sign the > > release: > > >> > > > > http://kafka.apache.org/KEYS > > >> > > > > > > >> > > > > * Release artifacts to be voted upon (source and binary): > > >> > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/ > > >> > > > > > > >> > > > > * Maven artifacts to be voted upon: > > >> > > > > https://repository.apache.org/content/groups/staging/ > > >> > > > > > > >> > > > > * java-doc > > >> > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/javadoc/ > > >> > > > > > > >> > > > > * tag to be voted upon (off 0.10.0 branch) is the 0.10.0.0 > tag: > > >> > > > > > > >> > > > > > > >> > > > > >> > > > >> > > > > > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=tag;h=065899a3bc330618e420673acf9504d123b800f3 > > > > >> > > > > > > >> > > > > * Documentation: > > >> > > > > http://kafka.apache.org/0100/documentation.html > > >> > > > > > > >> > > > > * Protocol: > > >> > > > > http://kafka.apache.org/0100/protocol.html > > >> > > > > > > >> > > > > /** > > >> > > > > > > >> > > > > Thanks, > > >> > > > > > > >> > > > > Gwen > > >> > > > > > > >> > > > > >> > > > >> > > > >> > > > >> > -- > > >> > -- Guozhang > > >> > > > >> > > >> > > >> > > >> -- > > >> Thanks, > > >> Ewen > > >> > > > > > > > > > > > > > > -- > Ashish 🎤h >
Re: [DISCUSS] scalability limits in the coordinator
Onur, Thanks for the investigation. Another option is to just fix how we deal with the case when a message is larger than the fetch size. Today, if the fetch size is smaller than the fetch size, the consumer will get stuck. Instead, we can simply return the full message if it's larger than the fetch size w/o requiring the consumer to manually adjust the fetch size. On the broker side, to serve a fetch request, we already do an index lookup and then scan the log a bit to find the message with the requested offset. We can just check the size of that message and return the full message if its size is larger than the fetch size. This way, fetch size is really for performance optimization, i.e. in the common case, we will not return more bytes than fetch size, but if there is a large message, we will return more bytes than the specified fetch size. In practice, large messages are rare. So, it shouldn't increase the memory consumption on the client too much. Jun On Sat, May 21, 2016 at 3:34 AM, Onur Karaman wrote: > Hey everyone. So I started doing some tests on the new consumer/coordinator > to see if it could handle more strenuous use cases like mirroring clusters > with thousands of topics and thought I'd share whatever I have so far. > > The scalability limit: the amount of group metadata we can fit into one > message > > Some background: > Client-side assignment is implemented in two phases > 1. a PreparingRebalance phase that identifies members of the group and > aggregates member subscriptions. > 2. an AwaitingSync phase that waits for the group leader to decide member > assignments based on the member subscriptions across the group. > - The leader announces this decision with a SyncGroupRequest. The > GroupCoordinator handles SyncGroupRequests by appending all group state > into a single message under the __consumer_offsets topic. This message is > keyed on the group id and contains each member subscription as well as the > decided assignment for each member. > > The environment: > - one broker > - one __consumer_offsets partition > - offsets.topic.compression.codec=1 // this is gzip > - broker has my pending KAFKA-3718 patch that actually makes use of > offsets.topic.compression.codec: https://github.com/apache/kafka/pull/1394 > - around 3000 topics. This is an actual subset of topics from one of our > clusters. > - topics have 8 partitions > - topics are 25 characters long on average > - one group with a varying number of consumers each hardcoded with all the > topics just to make the tests more consistent. wildcarding with .* should > have the same effect once the subscription hits the coordinator as the > subscription has already been fully expanded out to the list of topics by > the consumers. > - I added some log messages to Log.scala to print out the message sizes > after compression > - there are no producers at all and auto commits are disabled. The only > topic with messages getting added is the __consumer_offsets topic and > they're only from storing group metadata while processing > SyncGroupRequests. > > Results: > The results below show that we exceed the 112 byte > KafkaConfig.messageMaxBytes limit relatively quickly (between 30-40 > consumers): > 1 consumer 54739 bytes > 5 consumers 261524 bytes > 10 consumers 459804 bytes > 20 consumers 702499 bytes > 30 consumers 930525 bytes > 40 consumers 1115657 bytes * the tipping point > 50 consumers 1363112 bytes > 60 consumers 1598621 bytes > 70 consumers 1837359 bytes > 80 consumers 2066934 bytes > 90 consumers 2310970 bytes > 100 consumers 2542735 bytes > > Note that the growth itself is pretty gradual. Plotting the points makes it > look roughly linear w.r.t the number of consumers: > > https://www.wolframalpha.com/input/?i=(1,+54739),+(5,+261524),+(10,+459804),+(20,+702499),+(30,+930525),+(40,+1115657),+(50,+1363112),+(60,+1598621),+(70,+1837359),+(80,+2066934),+(90,+2310970),+(100,+2542735) > > Also note that these numbers aren't averages or medians or anything like > that. It's just the byte size from a given run. I did run them a few times > and saw similar results. > > Impact: > Even after adding gzip to the __consumer_offsets topic with my pending > KAFKA-3718 patch, the AwaitingSync phase of the group fails with > RecordTooLargeException. This means the combined size of each member's > subscriptions and assignments exceeded the KafkaConfig.messageMaxBytes of > 112 bytes. The group ends up dying. > > Options: > 1. Config change: reduce the number of consumers in the group. This isn't > always a realistic answer in more strenuous use cases like MirrorMaker > clusters or for auditing. > 2. Config change: split the group into smaller groups which together will > get full coverage of the topics. This gives each group member a smaller > subscription.(ex: g1 has topics starting with a-m while g2 has topics > starting ith n-z). This would be operationally painful to manage. > 3. Config change: split the topics among members of t
Re: [DISCUSS] scalability limits in the coordinator
Results without compression: 1 consumer 292383 bytes 5 consumers 1079579 bytes * the tipping point 10 consumers 1855018 bytes 20 consumers 2780220 bytes 30 consumers 3705422 bytes 40 consumers 4630624 bytes 50 consumers 826 bytes 60 consumers 6480788 bytes 70 consumers 7405750 bytes 80 consumers 8330712 bytes 90 consumers 9255674 bytes 100 consumers 10180636 bytes So it looks like gzip compression shrinks the message size by 4x. On Sat, May 21, 2016 at 9:47 AM, Jun Rao wrote: > Onur, > > Thanks for the investigation. > > Another option is to just fix how we deal with the case when a message is > larger than the fetch size. Today, if the fetch size is smaller than the > fetch size, the consumer will get stuck. Instead, we can simply return the > full message if it's larger than the fetch size w/o requiring the consumer > to manually adjust the fetch size. On the broker side, to serve a fetch > request, we already do an index lookup and then scan the log a bit to find > the message with the requested offset. We can just check the size of that > message and return the full message if its size is larger than the fetch > size. This way, fetch size is really for performance optimization, i.e. in > the common case, we will not return more bytes than fetch size, but if > there is a large message, we will return more bytes than the specified > fetch size. In practice, large messages are rare. So, it shouldn't increase > the memory consumption on the client too much. > > Jun > > On Sat, May 21, 2016 at 3:34 AM, Onur Karaman < > onurkaraman.apa...@gmail.com> > wrote: > > > Hey everyone. So I started doing some tests on the new > consumer/coordinator > > to see if it could handle more strenuous use cases like mirroring > clusters > > with thousands of topics and thought I'd share whatever I have so far. > > > > The scalability limit: the amount of group metadata we can fit into one > > message > > > > Some background: > > Client-side assignment is implemented in two phases > > 1. a PreparingRebalance phase that identifies members of the group and > > aggregates member subscriptions. > > 2. an AwaitingSync phase that waits for the group leader to decide member > > assignments based on the member subscriptions across the group. > > - The leader announces this decision with a SyncGroupRequest. The > > GroupCoordinator handles SyncGroupRequests by appending all group state > > into a single message under the __consumer_offsets topic. This message is > > keyed on the group id and contains each member subscription as well as > the > > decided assignment for each member. > > > > The environment: > > - one broker > > - one __consumer_offsets partition > > - offsets.topic.compression.codec=1 // this is gzip > > - broker has my pending KAFKA-3718 patch that actually makes use of > > offsets.topic.compression.codec: > https://github.com/apache/kafka/pull/1394 > > - around 3000 topics. This is an actual subset of topics from one of our > > clusters. > > - topics have 8 partitions > > - topics are 25 characters long on average > > - one group with a varying number of consumers each hardcoded with all > the > > topics just to make the tests more consistent. wildcarding with .* should > > have the same effect once the subscription hits the coordinator as the > > subscription has already been fully expanded out to the list of topics by > > the consumers. > > - I added some log messages to Log.scala to print out the message sizes > > after compression > > - there are no producers at all and auto commits are disabled. The only > > topic with messages getting added is the __consumer_offsets topic and > > they're only from storing group metadata while processing > > SyncGroupRequests. > > > > Results: > > The results below show that we exceed the 112 byte > > KafkaConfig.messageMaxBytes limit relatively quickly (between 30-40 > > consumers): > > 1 consumer 54739 bytes > > 5 consumers 261524 bytes > > 10 consumers 459804 bytes > > 20 consumers 702499 bytes > > 30 consumers 930525 bytes > > 40 consumers 1115657 bytes * the tipping point > > 50 consumers 1363112 bytes > > 60 consumers 1598621 bytes > > 70 consumers 1837359 bytes > > 80 consumers 2066934 bytes > > 90 consumers 2310970 bytes > > 100 consumers 2542735 bytes > > > > Note that the growth itself is pretty gradual. Plotting the points makes > it > > look roughly linear w.r.t the number of consumers: > > > > > https://www.wolframalpha.com/input/?i=(1,+54739),+(5,+261524),+(10,+459804),+(20,+702499),+(30,+930525),+(40,+1115657),+(50,+1363112),+(60,+1598621),+(70,+1837359),+(80,+2066934),+(90,+2310970),+(100,+2542735) > > > > Also note that these numbers aren't averages or medians or anything like > > that. It's just the byte size from a given run. I did run them a few > times > > and saw similar results. > > > > Impact: > > Even after adding gzip to the __consumer_offsets topic with my pending > > KAFKA-3718 patch, the AwaitingSync phase of the group fails with > > Rec
Re: [VOTE] 0.10.0.0 RC6
+1 (binding). Verified the quickstart. On Sat, May 21, 2016 at 9:22 AM, Ismael Juma wrote: > +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. And the > system tests passed on the 0.10.0 branch: > > https://jenkins.confluent.io/job/system-test-kafka-0.10.0/61/ > > Ismael > > On Sat, May 21, 2016 at 1:21 AM, Ashish Singh wrote: > > > +1, verified quickstart with source and binary release. > > > > On Saturday, May 21, 2016, Vahid S Hashemian > > wrote: > > > > > +1. I was able to successfully create a topic and run a producer and > > > consumer against it from the source on Ubuntu 15.04, Mac OS X Yosemite, > > > and Windows 7. > > > --Vahid > > > > > > > > > > > > From: Dana Powers > > > > To: "dev@kafka.apache.org " > > > > > > Date: 05/20/2016 12:13 PM > > > Subject:Re: [VOTE] 0.10.0.0 RC6 > > > > > > > > > > > > +1 -- passed kafka-python integration tests > > > > > > -Dana > > > > > > On Fri, May 20, 2016 at 11:16 AM, Joe Stein > > > wrote: > > > > +1 ran quick start from source and binary release > > > > > > > > On Fri, May 20, 2016 at 1:07 PM, Ewen Cheslack-Postava > > > > > > > > wrote: > > > > > > > >> +1 validated connect with a couple of simple connectors and console > > > >> producer/consumer. > > > >> > > > >> -Ewen > > > >> > > > >> On Fri, May 20, 2016 at 9:53 AM, Guozhang Wang > > > > > > wrote: > > > >> > > > >> > +1. Validated maven (should be > > > >> > > > > https://repository.apache.org/content/groups/staging/org/apache/kafka/ > > > >> > btw) > > > >> > and binary libraries, quick start. > > > >> > > > > >> > On Fri, May 20, 2016 at 9:36 AM, Harsha > > > wrote: > > > >> > > > > >> > > +1 . Ran a 3-node cluster with few system tests on our side. > Looks > > > >> good. > > > >> > > > > > >> > > -Harsha > > > >> > > > > > >> > > On Thu, May 19, 2016, at 07:47 PM, Jun Rao wrote: > > > >> > > > Thanks for running the release. +1 from me. Verified the > > > quickstart. > > > >> > > > > > > >> > > > Jun > > > >> > > > > > > >> > > > On Tue, May 17, 2016 at 10:00 PM, Gwen Shapira > > > > > > > >> > > wrote: > > > >> > > > > > > >> > > > > Hello Kafka users, developers and client-developers, > > > >> > > > > > > > >> > > > > This is the seventh (!) candidate for release of Apache > Kafka > > > >> > > > > 0.10.0.0. This is a major release that includes: (1) New > > > message > > > >> > > > > format including timestamps (2) client interceptor API (3) > > > Kafka > > > >> > > > > Streams. > > > >> > > > > > > > >> > > > > This RC was rolled out to fix an issue with our packaging > that > > > >> caused > > > >> > > > > dependencies to leak in ways that broke our licensing, and > an > > > issue > > > >> > > > > with protocol versions that broke upgrade for LinkedIn and > > > others > > > >> who > > > >> > > > > may run from trunk. Thanks to Ewen, Ismael, Becket and Jun > for > > > the > > > >> > > > > finding and fixing of issues. > > > >> > > > > > > > >> > > > > Release notes for the 0.10.0.0 release: > > > >> > > > > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/RELEASE_NOTES.html > > > >> > > > > > > > >> > > > > Lets try to vote within the 72h release vote window and get > > > this > > > >> baby > > > >> > > > > out already! > > > >> > > > > > > > >> > > > > *** Please download, test and vote by Friday, May 20, 23:59 > PT > > > >> > > > > > > > >> > > > > Kafka's KEYS file containing PGP keys we use to sign the > > > release: > > > >> > > > > http://kafka.apache.org/KEYS > > > >> > > > > > > > >> > > > > * Release artifacts to be voted upon (source and binary): > > > >> > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/ > > > >> > > > > > > > >> > > > > * Maven artifacts to be voted upon: > > > >> > > > > https://repository.apache.org/content/groups/staging/ > > > >> > > > > > > > >> > > > > * java-doc > > > >> > > > > http://home.apache.org/~gwenshap/0.10.0.0-rc6/javadoc/ > > > >> > > > > > > > >> > > > > * tag to be voted upon (off 0.10.0 branch) is the 0.10.0.0 > > tag: > > > >> > > > > > > > >> > > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=tag;h=065899a3bc330618e420673acf9504d123b800f3 > > > > > > >> > > > > > > > >> > > > > * Documentation: > > > >> > > > > http://kafka.apache.org/0100/documentation.html > > > >> > > > > > > > >> > > > > * Protocol: > > > >> > > > > http://kafka.apache.org/0100/protocol.html > > > >> > > > > > > > >> > > > > /** > > > >> > > > > > > > >> > > > > Thanks, > > > >> > > > > > > > >> > > > > Gwen > > > >> > > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > -- > > > >> > -- Guozhang > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Thanks, > > > >> Ewen > > > >> > > > > > > > > > > > > > > > > > > > > > > -- > > Ashish 🎤h > > > -- Thanks, Neha
