Our goal is to provide the best implementation of a set of useful
abstractions and features in Kafka. The motivation behind this philosophy
is performance and simplicity at the cost of flexibility. In most cases, we
can argue that the loss in flexibility is minimal since you can always get
that functionality by modeling your application differently, especially if
the system supports high performance. ActiveMQ has to support the JMS
protocol and hence provide all sorts of hooks and plugins on the brokers at
the cost of performance.

Could you elaborate more on your use case? There is probably another way to
model your application using Kafka.

On Sat, Jun 21, 2014 at 9:24 AM, ravi singh <[EMAIL PROTECTED]> wrote:
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