Home | About | Sematext search-lucene.com search-hadoop.com
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
 Search Hadoop and all its subprojects:

Switch to Plain View
Kafka >> mail # user >> Produce request failed due to NotLeaderForPartitionException (leader epoch is old)


+
Ivan Balashov 2015-06-17, 00:55
+
Jason Rosenberg 2013-06-23, 08:45
+
Sriram Subramanian 2013-06-23, 08:55
+
Jason Rosenberg 2013-06-23, 09:04
+
Jun Rao 2013-06-24, 03:23
+
Jason Rosenberg 2013-06-24, 07:23
+
Joel Koshy 2013-06-24, 08:57
+
Jun Rao 2013-06-24, 14:50
+
Joel Koshy 2013-06-24, 15:45
+
Jason Rosenberg 2013-06-24, 21:50
+
Jun Rao 2013-06-25, 04:05
+
Jason Rosenberg 2013-06-25, 04:50
+
Jun Rao 2013-06-25, 05:01
+
Jason Rosenberg 2013-06-25, 05:14
+
Jason Rosenberg 2013-06-25, 05:25
+
Jason Rosenberg 2013-06-25, 05:53
Copy link to this message
-
Re: produce request failed: due to Leader not local for partition
I added this scenario to KAFKA-955.

I'm thinking that this scenario could be a problem for ack=0 in general
(even without controlled shutdown).  If we do an "uncontrolled" shutdown,
it seems that some topics won't ever know there could have been a leader
change.  Would it make sense to force a meta-data refresh for all topics on
a broker, any time an IOException happens on a socket (e.g. "connection
reset")?  Currently, it looks like only the topic that experiences the
failure will have a metadata refresh issued for it.

Maybe this should be a separate jira issue, now that I think about it.

Jason
On Mon, Jun 24, 2013 at 10:52 PM, Jason Rosenberg <[EMAIL PROTECTED]> wrote:
 
+
Jun Rao 2013-07-01, 04:33
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