TopicConfigWatcher sounds good

I still feel there needs to be some abstraction to TopicConfigWather
because using Zookeeper Watcher means having global changes to a cluster
and in production we don't allow global updates to every server so i am
going to have to use another mechanism.  How we do many configuration
changes in production is to notify a server that ZK has a change and that
one server goes and gets the changes so we can do sequential configuration
changes with some sanity check for each server change is alright. one way
we do this is responding to http requests with name=value (i.e.
http://serverXYZ/admin/config=reload then hit a health check on serverXYZ).
 for scala servers we embed jetty.

if you can abstract the watcher that would be awesome or I can abstract it
after you are done and build another update.  I am not sold my way is
better for anyone that the ZK watcher I actually like that approach but if
others need or want the feature (like we would but i don't mind rolling a
patch into production that is not in the main code base) then we can agree
to support both methods.

also what about having a new package


this new class goes there

and another ticket refactoring other configs into there?  am I getting too
off my rocker to suggest re-packing kafka to org.apache.kafka? I don't mind
the code change in the kafka code but the downstream clients may freek...
but if we want to-do it now would be the time to-do it me thinks

On Thu, Jan 24, 2013 at 12:40 AM, Jay Kreps <[EMAIL PROTECTED]> wrote:

Joe Stein
Twitter: @allthingshadoop <>

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