Hi Yaar, Jun has been sending out really awesome updates on replication work. Check the list for a "replication status" email. He sends that out once a week (latest one here: http://mail-archives.apache.org/mod_mbox/incubator-kafka-dev/201206.mbox/%3CCAFbh0Q1vGQjcVC2Ep9dqcx-kvBboWe1SZM2oe0Ncdui547_FJw%40mail.gmail.com%3E). You can also follow progress in real-time via this JIRA and its many subtasks: https://issues.apache.org/jira/browse/KAFKA-50
Jun gave a great overview of the design and progress in the user group meeting which was recorded here: http://www.ustream.tv/recorded/23321300 The release plan is now sept, roughly. Much of that is tied to the roll out, which is somewhat unpredictable. We had divided work into the following phases: 1. Preparatory work (new request formats, async request handling, etc) 2.1 Basic multi-broker replication without fault-tolerance or producer acknowledgement 2.2 Fault-tolerance (leader election) and asynchronous producer acknowledgements (i.e. optionally block producer until message is replicated) 3. Operational features: partition migration, various corner-cases related to rolling restarts, other monitoring, tooling, and performance work. Phases 1 and 2.1 are complete. Phase 2.2 is in progress: there is a patch being reviewed for acknowledgements and the leadership election work is in progress. Phase 3 is not yet begun. -Jay On Mon, Jun 25, 2012 at 9:06 AM, Yaar Reuveni <sole.for...@gmail.com> wrote: > Hey, > > Are there any news about the ETA for Kafka version 0.8 release? > I saw an old thread about it from April > > http://mail-archives.apache.org/mod_mbox/incubator-kafka-users/201204.mbox/%3CCAOG_4QaHsP-Oi_R1XRs_5kzXXBZv2_CH5b=emi0gemshw5h...@mail.gmail.com%3E > where Neha said it might be released around August. is that still the plan? > > we are now researching the use of Kafka as our main message queuing system > for a new framework were building, > and version 0.8 has a few exiting new features for us like the replicatoin, > but even more interesting are the changes to the consumer API especially > the central consumer coordination. > we would like to be able to consume a topic with a few consumer groups, but > enable the same group to have multiple consumers > in adjacent locations/nodes and still have a balanced portioning for all of > them > we were looking at https://github.com/edwardcapriolo/IronCount as > a possible solution, but naturally it would be better if it > was supported directly by Kafka. > > Thanks, > Yaar >
