I'm curious the use case, but I think you'll need to use a combination of
ZooKeeper meta data and the TopicMetadata API.

The list of known topics for the cluster is in ZooKeeper:

Also in ZooKeeper is the list of Brokers.

To protect yourself from changes on how Kafka uses ZooKeeper I'd do the
- get the list of topics from ZooKeeper
- get the list of Brokers from ZooKeeper
- connect to the first Broker and use the list of topics to send
TopicMetadataRequest requests to figure out which partitions for the topic
are on which Broker (leader is what you want to know I think)

Since the leader assignments may change, be prepared for 'where' a
topic/partition lives to change. For example the Broker you are talking too
may suddenly be the leader for another topic/partition if that
topic/partition's leader failed and the current Broker was elected leader.
Depending on why you need to know about every topic/partition on a Broker
may have to listen on ZooKeeper events to see that this transition happened.

Hope this helps,
On Wed, Mar 13, 2013 at 3:38 AM, Snehalata Nagaje <
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