At the outset, this isn't about challenging the work that has been done,
primarily by folks @ Confluence for wrapping kafka in a REST API. Clearly,
there is a use case for a REST Service and they rose up to the challenge.
That said, I am trying to evaluate the limitations of a REST service around
Not out of the box, no - I don't think you can use an attribute of the
posted JSON to specify topics for kafka or folder for HDFS.
For dynamically creating topics in kafka, you would have to write some kind
of custom kafka producer - the kafka channel or sink in flume requires a
kafka topic to be
I have had a similar issue where I wanted a single source of truth between
Search and HDFS. First, if you zoom out a little, eventually you are going
to have some compute engine(s) process the data. If you store it in a
compute neutral tier like kafka then you will need to suck the data out at
Hi,
In the big data ecosystem, I have started to use kafka, essentially, as a:
- unordered list/array, and
- a cluster-wide pipe
I guess you could argue that any message bus product is a simple array/pipe
but kafka's scale and model make things so easy :)
I am wondering if there are any
don't end up scratching their heads :)
I think /kafka is just cleaner.
On Fri, Jan 23, 2015 at 9:34 AM, Jun Rao j...@confluent.io wrote:
Is the broker configured with the correct ZK url and the right namespace?
Thanks,
Jun
On Fri, Jan 23, 2015 at 12:17 AM, Tim Smith secs...@gmail.com
Using kafka 0.8.1.1, the cluster had been healthy with producers and
consumers being able to function well. After a restart of the cluster, it
looks like consumers are locked out.
When I try to consume from a topic, I get this warning:
[2015-01-23 07:48:50,667] WARN
