chia7712 commented on pull request #8657: URL: https://github.com/apache/kafka/pull/8657#issuecomment-669647781
@junrao I also don't want to include more mechanisms to complicate this story. It seems to me we can do a litter factor for ```DelayedOperation``` to resolve this issue. ```forceComplete``` is thread-safe already so it does not need lock. It means ```forceComplete``` can be decoupled from ```tryComplete```. With this change, ```forceComplete ``` is involved by ```maybeTryComplete``` and it is called after releasing lock. for example: ```scala private[server] def maybeTryComplete(): Boolean = { boolean timeToComplete = try lock.lock tryComplete() finally lock.unlock timeToComplete && forceComplete() } ``` Also, ```tryComplete``` can be renamed to ```canComplete```. the method name is consistent to its actual behavior. The benefit from this change are shown below. 1. simplify behavior of ```tryComplete```. the subclasses don't need to call ```forceComplete``` always 1. lower possibility of conflicting lock ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org