dajac commented on PR #14053:
URL: https://github.com/apache/kafka/pull/14053#issuecomment-1643446391

   @CalvinConfluent Thanks for the PR. There is indeed something fishy here. 
Could you please try to better explain the race condition in the description? 
My understanding is that we may pick the wrong broker epoch when we construct 
the AlterPartition request because we don't really respect the atomic reference 
(we read it multiple times vs working on a consistent snapshot). Is my 
understanding correct?
   
   If so, I agree that acquiring the isr lock solve the issue. However, it goes 
a bit against what we tried to achieve with the atomic reference. Our goal was 
to not acquire this lock. Therefore, I think that we should ensure that 
acquiring it does not impact the performances. Have we validated this? I also 
wonder if we could rework the shrink/expand paths to work based on a snapshot 
instead of acquiring the isr lock here.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to