Kafka, mail # user - Re: Non-blocking Kafka stream iterators - 2013-01-22, 22:35
Solr & Elasticsearch trainings in New York & San Fransisco [more info]
 Search Hadoop and all its subprojects:

Switch to Plain View
+
Ryan LeCompte 2013-01-21, 03:15
+
Jun Rao 2013-01-21, 06:16
+
Ryan LeCompte 2013-01-21, 06:18
+
navneet sharma 2013-01-21, 07:03
+
Jun Rao 2013-01-21, 16:06
+
Jay Kreps 2013-01-21, 17:27
+
Evan Chan 2013-01-22, 17:38
+
Jay Kreps 2013-01-22, 18:16
+
Evan Chan 2013-01-22, 18:53
+
Ryan LeCompte 2013-01-22, 18:55
+
Jay Kreps 2013-01-22, 20:47
+
Evan Chan 2013-01-22, 20:57
Copy link to this message
-
Re: Non-blocking Kafka stream iterators
Hey Guys,

One other potentially large benefit is to decouple broker dependencies
from consumer/producer dependencies. This makes upgrading the
consumer/producer and managing jar conflicts a lot less of a hassle.
Putting the consumer and producer in their own packages might hopefully
alleviate some of this. I'm not sure how much the broker is pulling in
that the consumer/producer aren't using, but it might be worth a look, if
there are a lot of jars that only the broker is using.

Cheers,
Chris

On 1/22/13 12:57 PM, "Evan Chan" <[EMAIL PROTECTED]> wrote:

 
+
Neha Narkhede 2013-01-23, 05:30
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB