xitep

Personally, I think this is an application level issue. I agree that with @netvl that this is very easy to get wrong by a general purpose xml parsing library such...

sounds reasonable to me. i'm fine with the proposal.

hello, this is a feature i would greatly desire myself to kafka-rust's `Consumer` client! thanks for the ticket. for smooth operation, though, i believe `Consumer` would need to be able...

i think it is of general interest to have it covered. feel free to work on this. btw: note, that `kafka-rust` itself doesn't use the [group membership api](https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol#AGuideToTheKafkaProtocol-GroupMembershipAPI) to coordinate...

just some notes on this issue: i see the following three candidates: - [mio](https://github.com/carllerche/mio) - very low-level (we probably don't want to go this path) - [futures-rs](https://github.com/alexcrichton/futures-rs/) - still feels...

@bluejekyll @pimeys feel free to tackle it (just talk to each other :)). i had some "getting familiar with mio/tokio" experiments last year, but i grew too busy in other...

yes, this is a (known) problem of `kafka-rust`; thanks for the ticket! from the top of my head: the problem is that when you send the `load_metadata` request, kafka will...

oh ... another, potentially less complicated workaround would be to: ``` client.load_metadata(&["my-topic"]).unwrap(); if !client.topics().contains("my-topic") { // 1) sleep for a while // 2) load_metadata again } ... producer.send(...); ```

ah ... i see. well, now, that the topic is created, but none of its partitions has a leader you hit probably a missleading error message. from the point of...

hm ... sounds like something's wrong within `kafka-rust` then :/