Re: Introducing Dory

Dory is pretty cool (even though it is named after a somewhat dorky fish). Thank you for sharing :) On Sun, Jun 12, 2016 at 1:24 AM, Dave Peterson wrote: > Hello Kafka users, > > Version 1.1.0 of Dory is now available. See > https://github.com/dspeterson/dory for details. Dory is the successor

Kafka controller replica state docs outdated?

Hello Apache Kafka community, Is it intentional that not all states (like ReplicaDeletionIneligible) are documented on https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Controller+Internals or is the page just outdated? Btw I see replica states documented in javadoc https://github.com/apach

Re: Introducing Dory

Thanks! Enjoy :-) On 6/12/2016 12:24 AM, Gwen Shapira wrote: Dory is pretty cool (even though it is named after a somewhat dorky fish). Thank you for sharing :) On Sun, Jun 12, 2016 at 1:24 AM, Dave Peterson wrote: Hello Kafka users, Version 1.1.0 of Dory is now available. See https://git

Re: Introducing Dory

Hi Dave, Dory looks pretty interesting. I had a few further questions on it a) How does Dory handle kernel panics? b) What kind of message guarantees does dory provide and also if you can share some design decisions taken to enable the guarantees whatever they are. Thanks Arya Arya On Sun, Jun

Running kafka connector application

Hi, I'm running the TwitterProducer task as per https://github.com/Eneco/kafka-connect-twitter connect-standalone /connect-source-standalone.properties /twitter-source.properties I see that I have to set the CLASSPATH to include all the dependent jars that the target connector jar is dependent

Storing results of a stream

Hi, I'm building a topology where I am connecting twitter with another application (ex: appA) appA also consists of the following graph model (similar to facebook/twitter) where a user can have followers and follow other users. Ex: UserA follows UserB, UserC, UserD. And UserB/C/D can have any n

Re: error: ... protocols are incompatible with those of existing members ??

Thanks Gwen, that was exactly my problem. I had changed the value of the group.id to the same value as the config name. But rereading the docs I did not find any hint of that this would occur. Did I miss it somewhere? -barry

Re: Any restrictions on consumer group name?

Adding the Kafka dev list to cc, hoping they would answer this question. -Jaikiran On Friday 10 June 2016 11:18 AM, Jaikiran Pai wrote: We are using 0.9.0.1 of Kafka server and (Java) clients. Our (Java) consumers are assigned to dynamic runtime generated groups i.e. the consumer group name is

session.timeout.ms was supplied but isn't a known config

In connect-distributed.properties I have values like: session.timeout.ms=12 But at startup I get warnings like: The configuration session.timeout.ms = 12 was supplied but isn't a > known config. I'm getting these warnings for most settings (eg, internal.key.converter, key.converter, b

Re: error: ... protocols are incompatible with those of existing members ??

More likely that we didn't think of documenting it :) Do you want to open a JIRA? or submit a doc patch? We should obviously document this limitation, but I'm thinking that the REST API could also validate that connector ID doesn't collide with the distributed worker group. On Mon, Jun 13, 2016