> On July 15, 2014, 5:51 p.m., Guozhang Wang wrote:
> > core/src/main/scala/kafka/server/ReplicaManager.scala, line 484
> > <https://reviews.apache.org/r/23474/diff/1/?file=631878#file631878line484>
> >
> >     I am wondering if this function will introduce more lock contention on 
> > leaderIsrUpdateLock? Every leaderReplicaIfLocal call will need to hold on 
> > its read lock while other requests at the same time may try to modify the 
> > leader option?

It might increase lock contention but writes to change the leadership occurs 
not so frequently so using readLock wouldn't be much of an issue I think. I 
also considered comparing ReplicaManager.localBrokerId with 
Partition.leaderReplicaIdOpt without a lock this will present an issue where 
the leader is changed and we might be comparing against old leader value.
Instead of using leaderReplicaIfLocal I can create another method "checkLeader" 
in Partition which will return a boolean after obtaining a readLock on 
leaderIsrUpdateLock. Right now there is unnecessary call going to getReplica.


- Sriharsha


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23474/#review47785
-----------------------------------------------------------


On July 15, 2014, 1:18 a.m., Sriharsha Chintalapani wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23474/
> -----------------------------------------------------------
> 
> (Updated July 15, 2014, 1:18 a.m.)
> 
> 
> Review request for kafka.
> 
> 
> Bugs: KAFKA-1483
>     https://issues.apache.org/jira/browse/KAFKA-1483
> 
> 
> Repository: kafka
> 
> 
> Description
> -------
> 
> KAFKA-1483. Split Brain about Leader Partitions.
> 
> 
> Diffs
> -----
> 
>   core/src/main/scala/kafka/server/ReplicaManager.scala 
> 6a56a772c134dbf1e70c1bfe067223009bfdbac8 
> 
> Diff: https://reviews.apache.org/r/23474/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sriharsha Chintalapani
> 
>

Reply via email to