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
