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
