It's correlated in the following way. Both the replica followers and the clients (producer and consumer) need to know the leader replica of a partition. If the leader of a partition fails, then (1) a new leader needs to be elected, which triggers LeaderAndIsr requests to be sent to the followers and (2) clients need to find out the new leader by issuing metadata requests.
Leader changes should only happen when brokers fail and should be rare. If there are too many leader changes, you probably need to look into soft broker failures introduced by GC. Thanks, jun On Thu, Jan 30, 2014 at 8:56 AM, Marek Dolgos <marek.dol...@webtrends.com>wrote: > We are seeing the following errors in our logs: > > [2014-01-30 15:18:40,736] 2134373909 [kafka-request-handler-3] ERROR > kafka.server.KafkaApis - [KafkaApi-10881778] Error while fetching metadata > for partition [las_01_scsRawHits,0] > > then they are always preceded or followed, within the same second, with: > > [2014-01-30 15:18:40,843] 2134374016 [kafka-request-handler-8] INFO > kafka.server.ReplicaManager - [Replica Manager on Broker 10881778]: > Handling LeaderAndIsr request > Name:LeaderAndIsrRequest;Version:0;Controller:10881777;ControllerEpoch:37;CorrelationId:836;ClientId:id_10881777-host_null-port_9092;PartitionState: > ... > > > Could the LeaderAndIsr request be a result of the error, or vice versa? > > If it makes a difference, out broker pair is handling many hundreds of > topics. > > Does the number of topics affect a LeaderAndIsr request? > > -Marek
