That's great. I would be happy to act as a point of contact if any questions come up or you need a reviewer for patches.
We haven't had an official discussion of roadmap but trunk already has support for keyed messages and log compaction and a cleanup of the log code. I think the goal would be to make this release as small and quick as possible with any bigger disruptive features going into 0.9. Here are some ideas of things that I think would fit well: 1. Any good housekeeping issues. 0.8 was a pretty major rewrite and getting that done and stable required ignoring a lot of basic issues that impact the out-of-the-box experience---good errors, documentation, logging, etc. We haven't filed a lot of JIRAs for this, but anything you see that falls under this umbrella would be a good target. Doing a few of these is often a good way to learn the code base. 2. Quotas. Jonathan had proposed working on this, but I don't think he ever got the time. https://issues.apache.org/jira/browse/KAFKA-656 3. Phase 2 of this wiki: https://cwiki.apache.org/confluence/display/KAFKA/Offset+Management
Folks--any other ideas?
On Sun, Jun 23, 2013 at 11:01 PM, Sam Meder <[EMAIL PROTECTED]> wrote:
The plan for branching is to do all development off trunk and cut branches for releases. 0.8 was sort of a one-off in this respect. Going forward the idea is that all new code will go against trunk.
Topic delete would also be a great one.
I would recommend we hold off on splitting the jars. I think post 0.8.1 (0.9?) would be a better target. The reason is that we have a bunch of major surgery to do there--move to nio, fix approach to request definition, redo producer and consumer api, etc--and I think it will be a lot easier to do all the surgery at once.
On Tue, Jun 25, 2013 at 7:53 AM, Sam Meder <[EMAIL PROTECTED]> wrote:
I actually don't think quotas really needs to do cross-broker communication. I think we can just enforce it at the topic-partition level and have the leader do the check (even if the user expresses the quota at the topic level we will just turn it into a per-partition limit by dividing by the number of partitions). If any one is interested in this I would be happy to help work through a design and help get it in.
-Jay On Tue, Jun 25, 2013 at 5:43 PM, S Ahmed <[EMAIL PROTECTED]> wrote:
Yes. And as you can see in that function, when no key is specified, it chooses a partition for each message in a round-robin manner, while we want to make all the messages in the same batch with the same topic to be sent to one partition.
So if the message is the first seen with the topic in the batch, we can choose one partition, but we want to stick to that partition with all the rest messages with the same topic in this batch.
Guozhang On Wed, Jul 3, 2013 at 11:18 AM, S Ahmed <[EMAIL PROTECTED]> wrote:
Yes. We will need to think a bit more for the more general case when there are messages for multiple topics.
Jun On Wed, Jul 3, 2013 at 11:18 AM, S Ahmed <[EMAIL PROTECTED]> wrote:
Jun Rao 2013-07-04, 04:32
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext