Yeah,

I see that with ack=0, the producer will be in a bad state anytime the
leader for it's partition has changed, while the broker that it thinks is
the leader is still up.  So this is a problem in general, not only for
controlled shutdown, but even for the case where you've restarted a server
(without controlled shutdown), which in and of itself can force a leader
change.  If the producer doesn't attempt to send a message during the time
the broker was down, it will never get a connection failure, and never get
fresh metadata, and subsequently start sending messages to the non-leader.

Thus, I'd say this is a problem with ack=0, regardless of controlled
shutdown.  Any time there's a leader change, the producer will send
messages into the ether.  I think this is actually a severe condition, that
could be considered a bug.  How hard would it be to have the receiving
broker forward on to the leader, in this case?

Jason
On Mon, Jun 24, 2013 at 8:44 AM, Joel Koshy <[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